Response to public hearing on the Consultation paper on the amendment of the RTS on SCA&CSC under PSD2
Go back
Firstly, it seems to be too early to assess said proposal: RTS on SCA & CSC have only been in force for two years and it took almost a year for ASPSP to initiate aggregation activity in the dedicated interface and use of 90-day exemption. An exhaustive analysis would be necessary to properly evaluated the impact of such change on the level of consumer protection and the level of consumer trust for open payments. These requirements must be correctly calibrated, otherwise they can have a negative effect on customer trust in Open Payments. Additionally, if there is a real and pressing need it cannot be ruled out that it would be more suitable to let the payment service user decide about enabling an exemption or not on an individual basis. Measures taken should increase the confidence and trust in all PSPs in the value chain.
Furthermore, the suggested amendment implies a delegation of SCA to AISPs and requires SCA only for the first time the user connects through the AISP. The obligation and responsibility to perform SCA lies solely on the ASPSP (Article 97 PSD2) and it is the ASPSP that issues the personalised security credentials. On the one hand, ASPSPs cannot rely on the AISPs to conduct SCA on the ASPSP’s behalf; on the other hand, ASPSPs cannot be forced to delegate SCA (as also confirmed by para 19 and 22 of the Consultation Paper). Therefore, clear guidance confirming the unambiguous responsibility of ASPSP as laid down in PSD2 is needed.
In addition, the proposed mandatory exemption violates the principle of equal treatment as it would inevitably lead to a different treatment of the direct channel and the dedicated interface. It would also cause limitation for ASPSPs in performing their own risk assessment to provide a higher level of security on the dedicated interface.
Finally, customers may get confused because they are faced with two different user experiences regarding the application of SCA when accessing their account directly (which is one of the consequences to be avoided by consistently applying PSD2 / SCA).
Additionally, an extension to 180 days could have the potential to reduce PSUs’ sovereignty over their data and increase risks. Extending the SCA to 180 days could increase the risk that fraudsters aggregate accounts and subsequently execute fraudulent payment transactions. The renewal of SCAs acts as both a security mechanism as well as a warning and information function. A period of 6 months without renewal of SCA or direct action of the PSU for third party data retrieval does not meet these requirements and will be at the disadvantage of PSUs. It is important to balance the objectives of convenience with fraud prevention and security, which are also key objectives of PSD2. The extension of the SCA validity to 180 days could increase the risk of fraud, as fraudsters could repeatedly have unauthorised access during the long timeframe of 180 days, obtaining lot of customer’s information more easily than currently. It could lead to a greater loss of confidence to the detriment of all market players.
The majority of Austrian banks are currently offering the 90 days exemption on their dedicated interfaces but don’t use this exemption in their own online banking interfaces. The exemption includes major risks in protecting the security of the payment service user’s data:
Even though AISPs can only access the last 90 days of the transaction data from the APIs without SCA, they will download the whole transaction history (due to a one-time SCA) and subsequent 180 days of transaction history (without SCA) into their system. This means that AISPs always have the whole transaction history at hand. Furthermore, AISPs are not required to request an SCA, so the customer and any other person accessing the PSU’s account on the AISP’s interface (possibly including malicious entities like scammers) will have access to the whole transaction history (loaded from the data stored by the AISP) without any SCA.
Currently if a PSU accesses the data in the AISP’s interface (without SCA), the AISP has the previous downloaded data on file in its system and is allowed to show this data to the PSU, including any sensitive data and an unrestricted transaction history.
To ensure a level playing field, AISP interfaces (PFP Apps etc.) should also be required to request an SCA from their PSUs if they want to show a transaction history older than 90 days or any sensitive payment data to their PSUs. AISPs can make use of the same exemptions from the SCA as already defined in the RTS. If a PSU is accessing the AISPs interface without SCA, then an AISP should only be allowed to show the balance, the last 90 days of transaction history and should not be allowed to show any sensitive payment data to the PSU.
Until more substantial evidence can be provided that a change as proposed in the EBA paper would benefit all customers, the EBA could also investigate the option of letting the customer determine if they want to set a 0, 90, or 180 day exemption. This would be a minimal intrusion in the customer flow, as the customer still needs to accept the exemption with an SCA. A possible suggestion is provided below:
2. Payment service providers shall not be exempted from the application of strong customer authentication where either of the following condition is met:
(a) the payment service user is accessing online the information specified in paragraph 1 for the first time;
(b) the payment service user has chosen to exempt the account servicing payment service provider from the application of strong customer authentication for 90 or 180 days since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.’
Overall, the impact of extending the timeline for the renewal of SCA has to be analyzed more thoroughly. It could be reconsidered in a few years’ time, once PSPs, PSUs, and authorities have gained more experience with customer needs, security concerns, and related data protection aspects.
Nevertheless, should EBA decide to extend the timeline from 90 to 180-days, a level playing field for all PSPs needs to be ensured by applying the same extension for the renewal of SCA to both the access through an AISP and when customers access directly the account information. The proposed exemption would only benefit one type of PSP i.e. the AISP. This would distort competition, deviating from the principle of “same activity, same risk, same rules”. A mandatory exemption to SCA would undermine the principle of equivalence of treatment and level playing field between PSPs. ASPSPs would be prevented from the application of SCA when PSUs access through AISPs although many require SCA every time the PSUs is accessing their account information directly. If introduced, the mandatory exemption should only be applied when the ASPSP also offers this exemption in the direct customer interface, which would be in line with Article 67(3)(b) of PSD2 i.e. that the ASPSP should treat AISP without any discrimination.
This new mandatory exemption would need to be implemented in the dedicated interfaces as well as the fallback (Article 33 Para 6 RTS). Changing both interfaces would mean extensive technical changes, tests and security reviews (especially for the fallback), which will push the timeline for finalizing the XS2A APIs back.
Changing the fallback interface to use a mandatory exemption from SCA of 180 days would result in adjusting the log-in session timeouts (after how long of inactivity are PSUs or PSPs logged out from the current online banking session), and a different handling of this timeout for example in the following cases:
AISPs would be able to access online available accounts for up to 180 consecutive days without SCA.
PISPs would be restricted to a session time to execute a transaction.
When PSUs are accessing the online banking interface, ASPSPs are required to terminate sessions after five minutes of inactivity (Article 4 (3) d) RTS).
On the other hand, the AISP interfaces do not have any restriction regarding PSU session timeouts, even though they do not require SCA. PSUs can login with only one factor and access the data inside the PSP interface without a maximum session duration or any restriction on the data displayed.
Having only 6 months adapting systems to these new requirements would introduce mayor risks in maintaining stable and secure banking services. Therefore, if banks offer a dedicated interface (although an exemption from the fallback is not finalized yet), they should only be required to change the dedicated interface and not their fallback interface.
In this regard it is also important that clear transitional rules are established: SCA-based consents that were given by a PSU before the application of the new rules should remain valid until the PSU gives a new consent according to the new rules.
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?
The proposal is seen critical for several reasons.Firstly, it seems to be too early to assess said proposal: RTS on SCA & CSC have only been in force for two years and it took almost a year for ASPSP to initiate aggregation activity in the dedicated interface and use of 90-day exemption. An exhaustive analysis would be necessary to properly evaluated the impact of such change on the level of consumer protection and the level of consumer trust for open payments. These requirements must be correctly calibrated, otherwise they can have a negative effect on customer trust in Open Payments. Additionally, if there is a real and pressing need it cannot be ruled out that it would be more suitable to let the payment service user decide about enabling an exemption or not on an individual basis. Measures taken should increase the confidence and trust in all PSPs in the value chain.
Furthermore, the suggested amendment implies a delegation of SCA to AISPs and requires SCA only for the first time the user connects through the AISP. The obligation and responsibility to perform SCA lies solely on the ASPSP (Article 97 PSD2) and it is the ASPSP that issues the personalised security credentials. On the one hand, ASPSPs cannot rely on the AISPs to conduct SCA on the ASPSP’s behalf; on the other hand, ASPSPs cannot be forced to delegate SCA (as also confirmed by para 19 and 22 of the Consultation Paper). Therefore, clear guidance confirming the unambiguous responsibility of ASPSP as laid down in PSD2 is needed.
In addition, the proposed mandatory exemption violates the principle of equal treatment as it would inevitably lead to a different treatment of the direct channel and the dedicated interface. It would also cause limitation for ASPSPs in performing their own risk assessment to provide a higher level of security on the dedicated interface.
Finally, customers may get confused because they are faced with two different user experiences regarding the application of SCA when accessing their account directly (which is one of the consequences to be avoided by consistently applying PSD2 / SCA).
Q2. Do you have any comments on the proposal to extend the timeline for the renewal of SCA to 180-days?
There is no need to extend the timeline for the renewal of SCA to 180-days. We do not experience any evidence that shows that the current 90-day period is an obstacle for product offerings or a reason for customer complaints. In the final report on draft RTS on SCA an CSC EBA/RTS/2017/02 EBA stated it considered 90 days to be an appropriate balance. There is a lack of substantial analysis on the real need to extend the timeline, and how such extension could impact the level of consumer integrity protection. Therefore, EBA is encouraged to further analyze the matter as part of the upcoming review of PSD2.Additionally, an extension to 180 days could have the potential to reduce PSUs’ sovereignty over their data and increase risks. Extending the SCA to 180 days could increase the risk that fraudsters aggregate accounts and subsequently execute fraudulent payment transactions. The renewal of SCAs acts as both a security mechanism as well as a warning and information function. A period of 6 months without renewal of SCA or direct action of the PSU for third party data retrieval does not meet these requirements and will be at the disadvantage of PSUs. It is important to balance the objectives of convenience with fraud prevention and security, which are also key objectives of PSD2. The extension of the SCA validity to 180 days could increase the risk of fraud, as fraudsters could repeatedly have unauthorised access during the long timeframe of 180 days, obtaining lot of customer’s information more easily than currently. It could lead to a greater loss of confidence to the detriment of all market players.
The majority of Austrian banks are currently offering the 90 days exemption on their dedicated interfaces but don’t use this exemption in their own online banking interfaces. The exemption includes major risks in protecting the security of the payment service user’s data:
Even though AISPs can only access the last 90 days of the transaction data from the APIs without SCA, they will download the whole transaction history (due to a one-time SCA) and subsequent 180 days of transaction history (without SCA) into their system. This means that AISPs always have the whole transaction history at hand. Furthermore, AISPs are not required to request an SCA, so the customer and any other person accessing the PSU’s account on the AISP’s interface (possibly including malicious entities like scammers) will have access to the whole transaction history (loaded from the data stored by the AISP) without any SCA.
Currently if a PSU accesses the data in the AISP’s interface (without SCA), the AISP has the previous downloaded data on file in its system and is allowed to show this data to the PSU, including any sensitive data and an unrestricted transaction history.
To ensure a level playing field, AISP interfaces (PFP Apps etc.) should also be required to request an SCA from their PSUs if they want to show a transaction history older than 90 days or any sensitive payment data to their PSUs. AISPs can make use of the same exemptions from the SCA as already defined in the RTS. If a PSU is accessing the AISPs interface without SCA, then an AISP should only be allowed to show the balance, the last 90 days of transaction history and should not be allowed to show any sensitive payment data to the PSU.
Until more substantial evidence can be provided that a change as proposed in the EBA paper would benefit all customers, the EBA could also investigate the option of letting the customer determine if they want to set a 0, 90, or 180 day exemption. This would be a minimal intrusion in the customer flow, as the customer still needs to accept the exemption with an SCA. A possible suggestion is provided below:
2. Payment service providers shall not be exempted from the application of strong customer authentication where either of the following condition is met:
(a) the payment service user is accessing online the information specified in paragraph 1 for the first time;
(b) the payment service user has chosen to exempt the account servicing payment service provider from the application of strong customer authentication for 90 or 180 days since the last time the payment service user accessed online the information specified in paragraph 1(b) and strong customer authentication was applied.’
Overall, the impact of extending the timeline for the renewal of SCA has to be analyzed more thoroughly. It could be reconsidered in a few years’ time, once PSPs, PSUs, and authorities have gained more experience with customer needs, security concerns, and related data protection aspects.
Nevertheless, should EBA decide to extend the timeline from 90 to 180-days, a level playing field for all PSPs needs to be ensured by applying the same extension for the renewal of SCA to both the access through an AISP and when customers access directly the account information. The proposed exemption would only benefit one type of PSP i.e. the AISP. This would distort competition, deviating from the principle of “same activity, same risk, same rules”. A mandatory exemption to SCA would undermine the principle of equivalence of treatment and level playing field between PSPs. ASPSPs would be prevented from the application of SCA when PSUs access through AISPs although many require SCA every time the PSUs is accessing their account information directly. If introduced, the mandatory exemption should only be applied when the ASPSP also offers this exemption in the direct customer interface, which would be in line with Article 67(3)(b) of PSD2 i.e. that the ASPSP should treat AISP without any discrimination.
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?
The suggested 6-month implementation timeline and estimated take effect from Q4 2022 onwards does not take into account that many ASPSPs have already fixed their implementation (IT) plans for the coming year, making it difficult to accommodate additional requirements that have to be implemented in 2022. Therefore, a 12-month implementation timeline with an estimated entry into force in 2023 would be more suitable.This new mandatory exemption would need to be implemented in the dedicated interfaces as well as the fallback (Article 33 Para 6 RTS). Changing both interfaces would mean extensive technical changes, tests and security reviews (especially for the fallback), which will push the timeline for finalizing the XS2A APIs back.
Changing the fallback interface to use a mandatory exemption from SCA of 180 days would result in adjusting the log-in session timeouts (after how long of inactivity are PSUs or PSPs logged out from the current online banking session), and a different handling of this timeout for example in the following cases:
AISPs would be able to access online available accounts for up to 180 consecutive days without SCA.
PISPs would be restricted to a session time to execute a transaction.
When PSUs are accessing the online banking interface, ASPSPs are required to terminate sessions after five minutes of inactivity (Article 4 (3) d) RTS).
On the other hand, the AISP interfaces do not have any restriction regarding PSU session timeouts, even though they do not require SCA. PSUs can login with only one factor and access the data inside the PSP interface without a maximum session duration or any restriction on the data displayed.
Having only 6 months adapting systems to these new requirements would introduce mayor risks in maintaining stable and secure banking services. Therefore, if banks offer a dedicated interface (although an exemption from the fallback is not finalized yet), they should only be required to change the dedicated interface and not their fallback interface.
In this regard it is also important that clear transitional rules are established: SCA-based consents that were given by a PSU before the application of the new rules should remain valid until the PSU gives a new consent according to the new rules.