Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
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.
Moreover, it is important to underline that PSD 2 principle of neutrality and of a level playing field for market incumbents and new players must be fully respected by the RTS, namely by guaranteeing that all measures imposed to AISP have to be fulfilled by both independent AISP and by the AIS provided by an ASPSP. The exact same restrictions should apply to both:
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. If the RTS establish a total amount of daily access for AIS it should be regardless if they are independent or provided by the ASPSP. If the PSU accesses his payment account twice through an independent AIS in the same day, then he will not be able to login to the electronic banking until tomorrow. If the access has to go through a strong authentication the first time and then once every month, it has to 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) shall be accessible through an independent AIS. If this is not the standard, then independent AIS will have no reason to exist, given that their primordial function is taken away from them. Moreover, it goes against the principle of data portability of the General Data Protection Regulation.
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. In order to guarantee full independence, the ASPSP AIS has to 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.
Any attempt by the RTS to restrict the PSU right to use and share his financial information or create obstacles to independent TPP to access information will place companies like FINTONIC at risk and affect the access of European Consumers to transparent information, unbiased advice and better and more competitive products.
When answering the specific questions we will keep in mind that the provisions proposed have to 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, should be amended.
Specific regarding Question 1, As we understand it, this chapter is not applicable to AISP as access to payment accounts through an AISP has to be exempt from strong customer authentication. What has to 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.
a. The use of the term payer instead of the term Payment Service User is misleading. Payment Service User should be used instead.
b. 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.
c. 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 has to be taken into account 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.
d. In i. the exemption excludes the first access to the payment account. It should be specified that this first time access has to 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.
e. In ii. It is implied that there has to 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 has to 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.
a. 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.
b. 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 guarantee the neutrality principle and a level playing field between independent AISP and the AIS of an ASPSP, the direct online access to the payment accounts (via the AIS of the ASPSP) should always be an option. 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.
c. 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).
d. 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 has to be the same.
e. Section 2.19.5. Determines a three-month period for publication of changes in communication technical specification before they are implemented. It is also 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.
f. 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.
g. 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.
h. 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).
i. Section 2.22.2. It should be specified that the notification messages have to be properly documented and be exhaustive and provide sufficient level of detail as to be valuable in the tracking and resolution of errors.
j. 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.
k. 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 between 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 personalised security credentials and authentication codes take place in secure environments in accordance with common security standards in compliance with ISO 27001. It has to be noted that this requirement has to be complied when there is direct online access to the payment accounts (the AIS of the ASPSP).
a. AIS are used to retrieve and aggregate data from the PSU account, on his behalf, after companies like FINTONIC, gives to the PSU, personalized experiences that go from financial education tools, optimising savings budget tools, positive credit scoring and financial products that better match the credit scoring, etc. If the RTS restrict AIS capacity to retrieve data and offer the best personalized service to the client, then by definition independent AIS will become obsolete.
b. 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.
c. Neutrality and level playing field: 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. 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 level playing field. The different treatment in this case would be imposing a lower limit of connections for an independent AISP vs the traditional online banking interface.
d. 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 PSD2principle of neutrality and equal level playing field.
e. 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?
First, as general remark we would like to state the following, FINTONIC is an independent Account Aggregator Service that outsources an independent Account Information Services to collect financial data information from the user account(s), at his request, from one and/or several different bank account, and aggregate them in one master account. After, FINTONIC offers its users/clients several services such as transaction categorisation, spending by category, spending history, budgeting tools, financial behaviour recommendation, alert system and pre approved loans and financial products based on the user credit score. FINTONIC exists because its users/clients voluntarily chose to share their financial information in order to have access to more suited financial products to their needs and often at better prices. Moreover, according to the European General Data Protection Regulation, the data is owned by the customer, in this context the PSU, and the PSU is free to decide with whom to share it, whether it is his accountant, personal advisor, tax assistant or virtual advisor in the form of a financial app (independent AIS). The RTS should not allow ASPSP to restrict data ownership or data portability, with a detrimental cost benefit effect 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.
Moreover, it is important to underline that PSD 2 principle of neutrality and of a level playing field for market incumbents and new players must be fully respected by the RTS, namely by guaranteeing that all measures imposed to AISP have to be fulfilled by both independent AISP and by the AIS provided by an ASPSP. The exact same restrictions should apply to both:
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. If the RTS establish a total amount of daily access for AIS it should be regardless if they are independent or provided by the ASPSP. If the PSU accesses his payment account twice through an independent AIS in the same day, then he will not be able to login to the electronic banking until tomorrow. If the access has to go through a strong authentication the first time and then once every month, it has to 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) shall be accessible through an independent AIS. If this is not the standard, then independent AIS will have no reason to exist, given that their primordial function is taken away from them. Moreover, it goes against the principle of data portability of the General Data Protection Regulation.
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. In order to guarantee full independence, the ASPSP AIS has to 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.
Any attempt by the RTS to restrict the PSU right to use and share his financial information or create obstacles to independent TPP to access information will place companies like FINTONIC at risk and affect the access of European Consumers to transparent information, unbiased advice and better and more competitive products.
When answering the specific questions we will keep in mind that the provisions proposed have to 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, should be amended.
Specific regarding Question 1, As we understand it, this chapter is not applicable to AISP as access to payment accounts through an AISP has to be exempt from strong customer authentication. What has to 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 can only partially agree with the reasoning.a. The use of the term payer instead of the term Payment Service User is misleading. Payment Service User should be used instead.
b. 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.
c. 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 has to be taken into account 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.
d. In i. the exemption excludes the first access to the payment account. It should be specified that this first time access has to 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.
e. In ii. It is implied that there has to 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 has to 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 personalised 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. Namelya. 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.
b. 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 guarantee the neutrality principle and a level playing field between independent AISP and the AIS of an ASPSP, the direct online access to the payment accounts (via the AIS of the ASPSP) should always be an option. 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.
c. 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).
d. 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 has to be the same.
e. Section 2.19.5. Determines a three-month period for publication of changes in communication technical specification before they are implemented. It is also 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.
f. 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.
g. 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.
h. 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).
i. Section 2.22.2. It should be specified that the notification messages have to be properly documented and be exhaustive and provide sufficient level of detail as to be valuable in the tracking and resolution of errors.
j. 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.
k. 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 between 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 has to be the same. Furthermore, adoption is still in its early stages within the financial sector as can be seen in• https://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 has to 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 personalised security credentials and authentication codes take place in secure environments in accordance with common security standards in compliance with ISO 27001. It has to be noted that this requirement has to 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 must be addressed:a. AIS are used to retrieve and aggregate data from the PSU account, on his behalf, after companies like FINTONIC, gives to the PSU, personalized experiences that go from financial education tools, optimising savings budget tools, positive credit scoring and financial products that better match the credit scoring, etc. If the RTS restrict AIS capacity to retrieve data and offer the best personalized service to the client, then by definition independent AIS will become obsolete.
b. 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.
c. Neutrality and level playing field: 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. 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 level playing field. The different treatment in this case would be imposing a lower limit of connections for an independent AISP vs the traditional online banking interface.
d. 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 PSD2principle of neutrality and equal level playing field.
e. 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.