Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
In that respect, it should be noted the fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP). Furthermore, per the European Data Protection Directive the data is owned by the PSU and he is free to decide with whom to share it. The contrary would jeopardize this directive and limit the portability of data.
The exact same restrictions should apply to both independent AIS and ASPSP providing AIS to the PSU:
- Same PSC. That is, the same user id and password for the ASPSP AIS (the electronic banking) than for any independent AIS. This would impede other passwords being revoked while the online banking can be accessed. In other words, if the credentials are revoked, they are revoked for everyone.
- Same restrictions. That is, if there are only two daily access (or whatever number may finally come out), this limit has to be respected for all (both independent AIS and AIS of the ASPSP – electronic banking). In order to respect the neutrality an ASPSP can't update the data whenever we wants or in real time while the independent AIS only can update it twice a day (or whatever number may finally come out). In the same way, if the access must go through a strong authentication the first time and then once every month, it must be for all AIS. Both independent AIS and ASPSP AIS (the electronic banking).
- Same information. Any information that is accessible through the AIS of the ASPSP (the electronic banking) is accessible through an independent AIS. Otherwise it would be against the Data Protection Directive. Any attempt by PSD2 to restrict PSU consumer rights to share his financial information or put difficulties in the way this information is accessed would not only put the business of AISP seriously at risk, it would also seriously affect the access of European Consumers to transparent information, unbiased advice and better and more competitive products.
- Same technology. If ISO 20022, ISO 27001 and eIDAS are imposed to AIS, then they are also imposed to ASPSP AIS (the electronic banking)
- Independence. To guarantee full independence, the ASPSP AIS must be one of the means available for independent AIS to access the PSU data. It is the only way to guarantee that the availability and the data that is available is the same for the ASPSP AIS (the electronic banking) and the independent AIS.
When answering this, and the following questions, we will keep in mind that the provisions proposed must be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, must be amended in the shortest possible time since they are identified.
As we understand it, this chapter is not applicable to AISP as access to payment accounts through an AISP must be exempt from strong customer authentication. What must be required is that level 1 of the PSC (typically a user ID and password) gives read only access to payment accounts. If level 1 of the PSC gives read only access to payment accounts, there is no need for strong authentication for AIS. As stated in preamble (96) of the directive, “The security measures should be compatible with the level of risk involved in the payment service.” In this case the risk does not justify the use of strong customer authentication.
In any case, we understand that the only way to guarantee neutrality and a level playing field is that the PSC that give access to a given ASPSP are unique for the PSU independently of the AISP chosen for access. In other words, there is only one set of PSC for every PSU ASPSP combination. If this is not the case, it will be impossible to ensure that they receive the same treatment.
- Revocation thresholds: if the PSC are different it is impossible to guarantee that the revocation thresholds and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
- Reactivation procedures: if the PSC are different it is impossible to guarantee that the reactivation procedures and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
The use of the term payer instead of the term Payment Service User is misleading. Payment Service User should be used instead.
It refers to access to payment accounts online in an unclear way. To all effects access to payment accounts online is an AIS, although it is provided directly by the ASPSP. The exemption should clearly include the access to payment accounts through an independent AISP whether it is initiated directly by the PSU or programmatically by the AISP, as there is no way for the ASPSP to distinguish between both. Otherwise it would be in violation of (21), (93) and (96) from the preamble and 98.2.d because it would not be a neutral measure and would not provide a level playing field between independent AISP and the AISP (electronic banking or PFM) of the ASPSP.
The term sensitive payment data requires further specification. The definition in PSD2 is ambiguous in that it is not exhaustive “(32) ‘sensitive payment data’ means data, including personalized security credentials which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;”. For the purposes of RTS the definition of what is and what is not sensitive payment data should be more complete. In addition, any information that is provided by the direct online access to the payment accounts (the AIS of the ASPSP) should be fully accessible through independent AISP, otherwise the principle of neutrality and equivalent operating conditions would be violated. It must be considered that the data ownership belongs to the PSU, and the RTS cannot limit its use or allow ASPSP to do so. Allowing such would go against the General Data Protection Regulation and the data portability principle.
In i. the exemption excludes the first access to the payment account. It should be specified that this first-time access must be independent of the access path. That is, it could be directly via the direct online access to the payment accounts (the AIS of the ASPSP) or indirectly via an independent AISP.
In ii. It is implied that there must be a strong authentication at least once every month. This is contrary to (96) which indicates that “The security measures should be compatible with the level of risk involved in the payment service.” In addition, currently ASPSP do not require this security measure for read only access to payment accounts, so it is surprising, that it is required in this RTS. Its admission would imply that currently electronic banking in Europe is not safe according to EBA for the majority of banks.” What must be required, as indicated in the answer to question 1, is that PSC have a first level of read only access, which would deem unnecessary any strong authentication.
Section 1. It is surprising that the section titled “General Requirements” has no general requirements that are applicable to AIS. This should need further clarification in order to bring certainty.
Section 2.19.1. It is said “Account servicing payment service providers that are offering to a payer a payment account that is accessible online shall offer at least one communication interface…”. It should be specified that in order to warrant the neutrality and a level playing field between independent AISP and the AIS of an ASPSP one of this interfaces has to be the direct online access to the payment accounts (the AIS of the ASPSP) with the same PSCs. The only difference should be that the communication requirements for authentication between independent AISP and the ASPSP are in place. This is the only practical way to ensure that the availability and the information that is accessible for the PSU is the same independently of the AIS chosen to access the payments information.
Section 2.19.1. (c) As noted above, the authentication process referred should use the same PSC for independent AISP as for direct online access to the payment accounts (the AIS of the ASPSP).
Section 2.19.3. ISO 20022 is not a widely recognized, accepted and mature standard and should not be used at this stage for the communication interface. However, if this is to be the final standard, then to respect and apply the principle of neutrality direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same.
Section 2.19.5. Determines a three-month period for publication of changes in communication technical specification before they are implemented. It is surprising that the procedure for emergency situations is specified before the standard procedure, where the change can be implemented without prior notification. It is required that:
Legitimate emergency situations are listed and defined.
A procedure for the notification of the emergency situation and the change in the technical specification for each emergency situation.
As the direct online access to the payment accounts (the AIS of the ASPSP) should be one of the communications interface it can be used as a backup by AISP in case others are not available. In case the change in technical specification affects the communication channel, direct online access to the payment accounts (the AIS of the ASPSP), if available, can be used until the conditions are restored. Otherwise there would be no neutrality and no level playing field.
Section 2.19.6. It should be specified that independent AISP can monitor the service level of both the direct online access to the payment accounts (the AIS of the ASPSP) as well as the alternative communications interface made available by ASPSP. This is the only way to ensure the same level of service is provided in both interfaces.
Section 2.22.2. Further definition of “as short as possible” and “as soon as the requested action has been completed” is required. As defined, ASPSP could impose a fixed time limit for a session to be completed and consider the requested action has been completed with an error code that specifies that the time limit has been exceeded.
Section 2.22.1.(a) Specifies that ASPSP shall provide the same information to AIS via the proposed communication interface as is available to the PSU directly online. However, an exception is made to the information that displays sensitive payment data. It shall be noted:
Unless “sensitive payment data” is exhaustively defined this is a potential loop hole that allows ASPSP to cherry-pick the information made available to independent AISP.
The fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP).
Section 2.22.2. It should be specified that the notification messages must be properly documented and be exhaustive and provide sufficient level of detail as to be valuable in the tracking and resolution of errors.
Section 2.22.5.(a) Determines that AISP can request information any time the PSU is requesting such information. However, it does not define how it is determined if the request is performed directly by the PSU or not actively requested as in 2.22.5.(b). A way for the AIS, independent AIS in particular, to inform the ASPSP that the request has been performed directly by the PSU has to be defined, and it has to be trusted. Otherwise 2.22.5.(a) is void.
Section 2.22.5.(b) Establishes a limit of no more than 2 connections a day when the user is not actively requesting such information. This does not ensure neutrality and a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP) unless the limit is shared and applied for both. Furthermore, the limit is suggested regardless of the result of the information request, which means that even in case of failure in retrieving the data it still counts. Therefore, if there is going to a limitation to the number of attempts, then the RTS should read “successful connections”.
https://www.iso20022.org/adoption.page and
https://www.iso20022.org/documents/adoption/ISO20022_Adoption_mApp_Overview.pptx.
Since it is not covered in any particular question we have included the following in the answer to this one, as it is where we see a closer relation. Article 221 6 requires that the processing and routing of personalized security credentials and authentication codes take place in secure environments in accordance with common security standards in compliance with ISO 27001. It must be noted that this requirement must be complied when there is direct online access to the payment accounts (the AIS of the ASPSP).
In order fulfil their function as Account Information Services, the AIS need to be able to retrieve financial data. The impossibility of doing so would make their existence superfluous.
The result of the request information: whatever the appropriate number is, it cannot be taken in isolation. The relevant number of requests is the number of successful requests. That is, the number of requests that have successfully obtained the requested information.
Neutrality and level playing field: whatever the appropriate number is, it must be the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP). If the payment user receives a different treatment depending on how he accesses his payment accounts this would be against PSD2 principle of neutrality and equal level playing field between market incumbents and new players. The different treatment in this case would be imposing a lower limit of connections for an independent AISP vs the traditional online banking interface.
The differentiation made between the payment service user requesting such information (22.5.a) vs the payment service user not actively requesting such information (22.5.b): since this distinction cannot be made when the payment service user is accessing his payment accounts through an independent AISP, it gives the direct online access to the payment accounts (the AIS of the ASPSP) a definite advantage over independent AISPs whether it is intentional or not. This goes against PSD2 principle of neutrality and equal level playing field.
The number of updates itself: 2 updates per day, even if they are successful is clearly not enough in many cases. Although it is understandable that banks want to limit the number in order to mitigate the load in their communication interface, it is too early to determine what the appropriate number is. Whatever the appropriate number is, it has to be either the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP) or a global measurer that can be consumed through any AISP.
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?
In terms of Account Information Services (AIS) and Account Information Service Providers (AISP) the following must be noted. The AISP is the provider that gives AIS to the PSU. The AISP can be independent from the ASPSP hosting the payment accounts, or it can be a service provided by the ASPSP. The electronic banking provided by an ASPSP (“direct online access to payment accounts” in the RTS) is an AISP for all purposes of PSD2 and for all purposes of the RTS. Consequently, in order to fulfil the neutrality and level playing field aimed by PSD2, all measures imposed to AISP have to be fulfilled by both independent AISP and by the AIS provided by an ASPSP. So, for all the questions we will keep in mind that the provisions proposed must be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, must be amended in the shortest possible time since they are identified.In that respect, it should be noted the fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP). Furthermore, per the European Data Protection Directive the data is owned by the PSU and he is free to decide with whom to share it. The contrary would jeopardize this directive and limit the portability of data.
The exact same restrictions should apply to both independent AIS and ASPSP providing AIS to the PSU:
- Same PSC. That is, the same user id and password for the ASPSP AIS (the electronic banking) than for any independent AIS. This would impede other passwords being revoked while the online banking can be accessed. In other words, if the credentials are revoked, they are revoked for everyone.
- Same restrictions. That is, if there are only two daily access (or whatever number may finally come out), this limit has to be respected for all (both independent AIS and AIS of the ASPSP – electronic banking). In order to respect the neutrality an ASPSP can't update the data whenever we wants or in real time while the independent AIS only can update it twice a day (or whatever number may finally come out). In the same way, if the access must go through a strong authentication the first time and then once every month, it must be for all AIS. Both independent AIS and ASPSP AIS (the electronic banking).
- Same information. Any information that is accessible through the AIS of the ASPSP (the electronic banking) is accessible through an independent AIS. Otherwise it would be against the Data Protection Directive. Any attempt by PSD2 to restrict PSU consumer rights to share his financial information or put difficulties in the way this information is accessed would not only put the business of AISP seriously at risk, it would also seriously affect the access of European Consumers to transparent information, unbiased advice and better and more competitive products.
- Same technology. If ISO 20022, ISO 27001 and eIDAS are imposed to AIS, then they are also imposed to ASPSP AIS (the electronic banking)
- Independence. To guarantee full independence, the ASPSP AIS must be one of the means available for independent AIS to access the PSU data. It is the only way to guarantee that the availability and the data that is available is the same for the ASPSP AIS (the electronic banking) and the independent AIS.
When answering this, and the following questions, we will keep in mind that the provisions proposed must be neutral and provide a level playing field between independent AISP and AIS provided by the ASPSP which is the purpose of PSD2 in regards to AIS. Any provisions that do not guarantee neutrality or a level playing field, now or in the future, must be amended in the shortest possible time since they are identified.
As we understand it, this chapter is not applicable to AISP as access to payment accounts through an AISP must be exempt from strong customer authentication. What must be required is that level 1 of the PSC (typically a user ID and password) gives read only access to payment accounts. If level 1 of the PSC gives read only access to payment accounts, there is no need for strong authentication for AIS. As stated in preamble (96) of the directive, “The security measures should be compatible with the level of risk involved in the payment service.” In this case the risk does not justify the use of strong customer authentication.
In any case, we understand that the only way to guarantee neutrality and a level playing field is that the PSC that give access to a given ASPSP are unique for the PSU independently of the AISP chosen for access. In other words, there is only one set of PSC for every PSU ASPSP combination. If this is not the case, it will be impossible to ensure that they receive the same treatment.
- Revocation thresholds: if the PSC are different it is impossible to guarantee that the revocation thresholds and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
- Reactivation procedures: if the PSC are different it is impossible to guarantee that the reactivation procedures and treatment are the same for different sets of PSC as the ASPSP has vested interests in one of them.
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?
We partially agree with the reasoning.The use of the term payer instead of the term Payment Service User is misleading. Payment Service User should be used instead.
It refers to access to payment accounts online in an unclear way. To all effects access to payment accounts online is an AIS, although it is provided directly by the ASPSP. The exemption should clearly include the access to payment accounts through an independent AISP whether it is initiated directly by the PSU or programmatically by the AISP, as there is no way for the ASPSP to distinguish between both. Otherwise it would be in violation of (21), (93) and (96) from the preamble and 98.2.d because it would not be a neutral measure and would not provide a level playing field between independent AISP and the AISP (electronic banking or PFM) of the ASPSP.
The term sensitive payment data requires further specification. The definition in PSD2 is ambiguous in that it is not exhaustive “(32) ‘sensitive payment data’ means data, including personalized security credentials which can be used to carry out fraud. For the activities of payment initiation service providers and account information service providers, the name of the account owner and the account number do not constitute sensitive payment data;”. For the purposes of RTS the definition of what is and what is not sensitive payment data should be more complete. In addition, any information that is provided by the direct online access to the payment accounts (the AIS of the ASPSP) should be fully accessible through independent AISP, otherwise the principle of neutrality and equivalent operating conditions would be violated. It must be considered that the data ownership belongs to the PSU, and the RTS cannot limit its use or allow ASPSP to do so. Allowing such would go against the General Data Protection Regulation and the data portability principle.
In i. the exemption excludes the first access to the payment account. It should be specified that this first-time access must be independent of the access path. That is, it could be directly via the direct online access to the payment accounts (the AIS of the ASPSP) or indirectly via an independent AISP.
In ii. It is implied that there must be a strong authentication at least once every month. This is contrary to (96) which indicates that “The security measures should be compatible with the level of risk involved in the payment service.” In addition, currently ASPSP do not require this security measure for read only access to payment accounts, so it is surprising, that it is required in this RTS. Its admission would imply that currently electronic banking in Europe is not safe according to EBA for the majority of banks.” What must be required, as indicated in the answer to question 1, is that PSC have a first level of read only access, which would deem unnecessary any strong authentication.
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?
We agree that the personalized security credentials require an adequate level of protection. However, as chapter 3 is written only Article 9 is applicable to AIS, although this should be more explicit.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?
We agree that the use of a common and secure open standard is desirable for the purpose of identification, authentication, notification and information. However, we disagree on several of the resultant provisions proposed in chapter 4. NamelySection 1. It is surprising that the section titled “General Requirements” has no general requirements that are applicable to AIS. This should need further clarification in order to bring certainty.
Section 2.19.1. It is said “Account servicing payment service providers that are offering to a payer a payment account that is accessible online shall offer at least one communication interface…”. It should be specified that in order to warrant the neutrality and a level playing field between independent AISP and the AIS of an ASPSP one of this interfaces has to be the direct online access to the payment accounts (the AIS of the ASPSP) with the same PSCs. The only difference should be that the communication requirements for authentication between independent AISP and the ASPSP are in place. This is the only practical way to ensure that the availability and the information that is accessible for the PSU is the same independently of the AIS chosen to access the payments information.
Section 2.19.1. (c) As noted above, the authentication process referred should use the same PSC for independent AISP as for direct online access to the payment accounts (the AIS of the ASPSP).
Section 2.19.3. ISO 20022 is not a widely recognized, accepted and mature standard and should not be used at this stage for the communication interface. However, if this is to be the final standard, then to respect and apply the principle of neutrality direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same.
Section 2.19.5. Determines a three-month period for publication of changes in communication technical specification before they are implemented. It is surprising that the procedure for emergency situations is specified before the standard procedure, where the change can be implemented without prior notification. It is required that:
Legitimate emergency situations are listed and defined.
A procedure for the notification of the emergency situation and the change in the technical specification for each emergency situation.
As the direct online access to the payment accounts (the AIS of the ASPSP) should be one of the communications interface it can be used as a backup by AISP in case others are not available. In case the change in technical specification affects the communication channel, direct online access to the payment accounts (the AIS of the ASPSP), if available, can be used until the conditions are restored. Otherwise there would be no neutrality and no level playing field.
Section 2.19.6. It should be specified that independent AISP can monitor the service level of both the direct online access to the payment accounts (the AIS of the ASPSP) as well as the alternative communications interface made available by ASPSP. This is the only way to ensure the same level of service is provided in both interfaces.
Section 2.22.2. Further definition of “as short as possible” and “as soon as the requested action has been completed” is required. As defined, ASPSP could impose a fixed time limit for a session to be completed and consider the requested action has been completed with an error code that specifies that the time limit has been exceeded.
Section 2.22.1.(a) Specifies that ASPSP shall provide the same information to AIS via the proposed communication interface as is available to the PSU directly online. However, an exception is made to the information that displays sensitive payment data. It shall be noted:
Unless “sensitive payment data” is exhaustively defined this is a potential loop hole that allows ASPSP to cherry-pick the information made available to independent AISP.
The fact that certain payment information is available to the PSU from direct online access to the payment accounts (the AIS of the ASPSP) that is not available when the PSU access his information via an independent AIS is clearly against the principle of neutrality and does not provide a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP).
Section 2.22.2. It should be specified that the notification messages must be properly documented and be exhaustive and provide sufficient level of detail as to be valuable in the tracking and resolution of errors.
Section 2.22.5.(a) Determines that AISP can request information any time the PSU is requesting such information. However, it does not define how it is determined if the request is performed directly by the PSU or not actively requested as in 2.22.5.(b). A way for the AIS, independent AIS in particular, to inform the ASPSP that the request has been performed directly by the PSU has to be defined, and it has to be trusted. Otherwise 2.22.5.(a) is void.
Section 2.22.5.(b) Establishes a limit of no more than 2 connections a day when the user is not actively requesting such information. This does not ensure neutrality and a level playing field between independent AIS and direct online access to the payment accounts (the AIS of the ASPSP) unless the limit is shared and applied for both. Furthermore, the limit is suggested regardless of the result of the information request, which means that even in case of failure in retrieving the data it still counts. Therefore, if there is going to a limitation to the number of attempts, then the RTS should read “successful connections”.
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?
ISO 20022 is not a widely recognized, accepted and mature standard and should not be used at this stage for the communication interface. However, it should be noted that if this was the final standard to be used, direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same. Furthermore, adoption is still in its early stages within the financial sector as can be seen inhttps://www.iso20022.org/adoption.page and
https://www.iso20022.org/documents/adoption/ISO20022_Adoption_mApp_Overview.pptx.
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 ?
We agree on the use of website certificates issued by a qualified trust service provider for AIS authentication. However, eIDAS is not a mature standard and should not be used at this stage for the communication interface. However, it should be noted that if this was the final standard to be used, direct online access to the payment accounts (the AIS of the ASPSP) would have to connect to the ASPSP using the same standard in the same way as the communication interface must be the same.Since it is not covered in any particular question we have included the following in the answer to this one, as it is where we see a closer relation. Article 221 6 requires that the processing and routing of personalized security credentials and authentication codes take place in secure environments in accordance with common security standards in compliance with ISO 27001. It must be noted that this requirement must be complied when there is direct online access to the payment accounts (the AIS of the ASPSP).
Question 10: With regards to the frequency with which AIS providers can request information from designated payment accounts when the payment service user is not actively requesting such information, do you agree that the proposed limit of no more than two times a day achieve an appropriate balance between allowing AISP to provide updated information to their users while not negatively impacting the availability of the ASPSP’s communication interface? If not, please indicate what would be in your view the appropriate frequency and rationale for such frequency.
There are several issues around this matter that require further analysis:In order fulfil their function as Account Information Services, the AIS need to be able to retrieve financial data. The impossibility of doing so would make their existence superfluous.
The result of the request information: whatever the appropriate number is, it cannot be taken in isolation. The relevant number of requests is the number of successful requests. That is, the number of requests that have successfully obtained the requested information.
Neutrality and level playing field: whatever the appropriate number is, it must be the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP). If the payment user receives a different treatment depending on how he accesses his payment accounts this would be against PSD2 principle of neutrality and equal level playing field between market incumbents and new players. The different treatment in this case would be imposing a lower limit of connections for an independent AISP vs the traditional online banking interface.
The differentiation made between the payment service user requesting such information (22.5.a) vs the payment service user not actively requesting such information (22.5.b): since this distinction cannot be made when the payment service user is accessing his payment accounts through an independent AISP, it gives the direct online access to the payment accounts (the AIS of the ASPSP) a definite advantage over independent AISPs whether it is intentional or not. This goes against PSD2 principle of neutrality and equal level playing field.
The number of updates itself: 2 updates per day, even if they are successful is clearly not enough in many cases. Although it is understandable that banks want to limit the number in order to mitigate the load in their communication interface, it is too early to determine what the appropriate number is. Whatever the appropriate number is, it has to be either the same number of requests for an independent AISP or direct online access to the payment accounts (the AIS of the ASPSP) or a global measurer that can be consumed through any AISP.