Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
This document outlines Accenture’s response to EBA’s open consultation on the draft Regulatory Technical Standards (“RTS”) specifying the requirements on strong customer authentication and common and secure communication under PSD2 published on 12 August 2016.
Accenture provides a range of consulting, technology and outsourcing services supporting technical infrastructure of payments and cards processes to various retailers, banks and payment processors. We are helping banks to build their open banking capabilities and innovative business models. Through this work, we have experience of the trends and hot topics in the payments industry in Europe and globally, and their impact on organisations and consumers. Open banking, open APIs, e- and mCommerce including payments are one of these issues and, as such, we welcome the opportunity to answer the EBA Consultation Paper on future Regulatory Technical Standards on strong customer authentication and common and secure communication under PSD2.
Our response starts with a short discussion on the fast changing payments landscape to set the context for our answers to the 10 consultation questions which follow.
2. Context
The EBA acknowledges in the Consultation Paper that it has made difficult trade-offs between competing demands – for example between security and innovation, between innovation and the risk of fragmentation and between authentication and user-friendliness.
In making these trade-offs, and in defining the final RTS the following factors are important:
o The balance between high security standards and user convenience, in particular the facilitation of frictionless payments
o The impact on competition, not just competition between banks, but also between new entrants, FinTech and non-bank PSPs
o The digital environment in which consumers operate, the digital devices they utilise and the network connectivity that is available to them
o The different needs and business models (including new business models) of merchants, which are diverse and changing with innovation and consumer expectations.
Accenture believes that frictionless payments are important to the consumer experience in the digital world and to the adoption of digital services that depend on them. Payments that are easy and convenient allow consumers to enjoy the services they are paying for without detraction, which in turn helps adoption and growth of those services. Evidence for the importance of frictionless payments includes Uber (card-on-file), Starbucks (mobile payments) and Amazon (One-Click). RTS should facilitate frictionless payments appropriately to support the growth of the digital economy.
In the past decade, much of the innovation in the digital world has come from FinTechs, new entrants and new business models – Google, Amazon, Facebook, Instagram, and Twitter are some examples. It follows therefore that FinTechs and new entrants are creating a new competitive environment for the payments landscape and for banks, which have a positive effect on consumers and the economy. The RTS therefore should address the needs of both established PSPs and new entrants in order to enable competition.
The digital environment in which consumers operate is also a major consideration, in particular because the environment is not uniform, and varies geographically and demographically. This environment is multi-channel – online, mobile, POS, machine-to-machine, and uses different forms of network connectivity (internet, wifi, broadband, GPS, Bluetooth, NFC, GPRS etc). Multiple combinations of technologies are involved and not all are available everywhere the customer acts in his everyday life, e.g. wifi coverage, mobile reception coverage, or suited to their lifestyle e.g. smartphone and device usage. The RTS cannot predict these combinations, but they should also be careful to avoid making assumptions that consumers have, or want, uniform access to all technologies, all the time, in all places.
Finally, digital drives new business models and new digital businesses that cannot always be predicted. This is a challenge for the RTS as they impact businesses and business models that do not yet even exist. The PSD2 itself exists because it addresses a digital environment that did not exist when the original PSD was drafted ten years ago. Therefore it is important that the RTS do not unintentionally restrict the development of new businesses and their business models. This means the RTS needs to be flexible to allow AISPs, PISPs and ASPSPs, Fintech companies and other PSPs to operate within their own risk parameters and take their own risk decisions when it comes to fraud detection or exemptions from strong customer authentication. For example, in the cards world, ecommerce merchants often decide to turn off the “Verified-by” (3D-Secure) function. This increases their fraud risk and shifts liability to them, but it is a choice they make to reduce friction at checkout to increase completed sales.
These points set the context for our answers to this question Q1 and to the other nine questions that follow:
The requirements in Chapter 1 on authentication methods and the independency of channels should be defined to allow for a balance between strong security requirements and user convenience and allow TPPs (such as FinTechs) to develop new innovative business models. In particular, these can depend on payments being frictionless – easy and convenient for consumers. TPPs can rely on the existing authentication methods of the ASPSP (Article 97.5 PSD2), but the RTS needs to state clearly that while ASPSPs should be responsible for implementing authentication methods, they should also make them available to TPPs.
The independence of channels plays a vital role in a multi-channel and especially mobile ecosystem of desktops, mobile devices (smartphones, tablets, and watches etc.) and mobile applications. It is important that the authentication code is not transmitted through the same channel that the customer has initiated the authentication procedure. Two options for consideration in this context are:
• Using two separate devices – one for the initiation of the authentication procedure (e.g. smartphone) and one for the reception or generation of the authentication code (token device). This option is the most inconvenient way of implementing independence of channels. The user would need to carry two devices to make payments online or at POS.
• Using one device for the initiation of the authentication procedure and the reception of the authentication code (e.g. authentication code initiated via a web browser on the smartphone, with the authentication code received via a mobile application on the same smartphone device). In our view, this option needs more attention and needs to be promoted in the RTS as the best way forward. Therefore, there should be minimum requirements defined for the technical separation of the different authentication elements (device’s operating system and the mobile application receiving the authentication code on the same device). It needs to be ensured that innovative authentication elements and methods should not be discriminated against.
• It is unclear whether this would put in place a restriction on the use of the mobile device as both the payment initiator channel and the authentication code recipient channel.
• Clarification on when the segregation of channel, app, mobile, device are acceptable is required in the RTS (considered against wider security and other trade-offs).
• Clarification is required on which biometric technologies are to be supported as minimum requirements (e.g. fingerprints, face and voice recognition, iris scan) and the security requirements on storage of this sensitive data by the ASPSP.
• Threats related to the reply of the authentication information in the possession and inherence category are not specified. This threat is more hazardous to inherence based authentication (if compromised) considering the inherence related factors cannot be altered easily (for e.g. finger print pattern/iris scan), if attackers find ways to reply with this information during the authentication phase.
• It would be beneficial to refer to the inherence capturing mechanism/channel in the RTS.
• Even though the topic behavioural data analysis is not part of the authentication elements, we note that “behavioural data” is not included in the RTS as a fraud prevention mechanism, but consider it should not be excluded. There are multiple highly innovative companies developing fraud prevention and authentication methods using behavioural data and hence help improving user convenience and experience, not least because these methods allow for continuous and “invisible” authentication of the user.
• However, there are multiple questions that require consideration:
o Is the ASPSP the only entity that is permitted to verify exemptions? TPPs (AISP, PISP, PSP) should be granted with the possibility to overrule the exemption rules if requested by the user.
o Is there a time limit for the validity of the “cumulative amount” (150 EUR for contactless through a PSP and 100 EUR for credit transfers through a PISP) or is it valid for an unlimited timeframe?
o In order to make online payments initiated through TPPs successful on the market, the exemption amount of 10 EUR for a credit transfer is not sufficient since the average order value in eCommerce and POS is higher than 50 EUR. An increased exemption amount up to 50 EUR should be considered to ensure a frictionless user experience (see UK average debit card value of £43.43, http://uk.creditcards.com/credit-card-news/uk-britain-credit-debit-card-statistics-international.php). Alternatively, it should be thought of not to define any fixed exemption amounts and leave it configurable for the PSP and the user to determine
o In case of fraud, TPPs and ASPSPs must be in a position to prove if all security measures were applied on a transaction. If the TPP or ASPSP applied an exemption for a transaction that proved fraudulent, the TPP or ASPSP need to compensate the losses. It is important that the RTS enables them to decide if they allow exemptions or not. Otherwise it is not clear which party covers the risk of fraud in the context of an exemption. The RTS should enable TPPs and ASPSPs to operate within their own risk parameters and make their own risk decisions. For example, in the cards world, ecommerce merchants often decide to turn off the “Verified-by” (3D-Secure) function. This increases their fraud risk and shifts liability to them, but it is a choice they make to reduce friction at checkout to increase completed sales.
• Another aspect that needs to be detailed out is the exemption rules for AISPs in Article 8.1a. The RTS states that the AISP shall not be exempted where the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, for the first time or later than one month after the last day in which strong customer authentication was applied. Where there are multiple information requests in a short time period, the user will not be asked for strong customer authentication and not to enter user credentials and authentication code each time data is requested. In order to enable TPPs such as FinTechs and PSPs to develop successful user-friendly applications and avoid friction, there is a need for a technical mechanism and infrastructure from the ASPSP to cater for this function. Tokenisation Services could be a possible approach to permit TPPs accessing the payment account multiple times using a token without going through the entire authentication process again.
• However, the described interfaces, mechanisms and formats (ISO20022 or other industry standards) need to be specified in terms of minimum technical requirements e.g. basic mechanisms and field level information which will make it less complex to implement these interfaces at the TPP’s side. A tendency towards more harmonisation would be desirable.
• For the intended benefits of the PSD2 and ease of operations for PSPs and TPPs it would be beneficial to provide some guidance on some open standards. Without specification of these open standards there is the possibility of interoperability issues, especially for TPPs where each PSP may have different interpretation.
• Specifying standards such as OAuth 2.0 and OpenID connect, can help PSPs prepare themselves for these technologies in the PSD2 world. Obviously, as technology moves on these, standards will inevitably change or even be replaced, but it gives everyone now a common starting position, and any changes can be introduced after future consultations.
• It would be beneficial to specify a qualified trust provider as the registration authority along with mandating security checks (such as revocation) during certificate based authentication.
• To increase certainty, the final RTS could provide greater detail on:
o the high level End-to-End certification process of a PSP, even if each member state has autonomy
o the guidelines for mandatory information required for certificate issuance
o the information of the PSP needed to be in place at the ASPSP-side to perform the authentication verification process
o the minimum technical standards to prevent service denial situation between a PSP and TPP.
• In our view, the ASPSP should provide the user with an access control function in order to manage all access rights that were given to TPPs to access the payment account. This access control function should be specified in the final RTS.
• Further, availability of a real-time balance can be an important component of the consumer experience when making digital payments – it therefore follows that PISPs who are also AISPs are likely to request real-time balance information before and immediately after a payment. Therefore it is reasonable for a PISP or AISP to request account balance information with a frequency that is dependent on the consumer’s frequency of payments.
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?
1. Introduction:This document outlines Accenture’s response to EBA’s open consultation on the draft Regulatory Technical Standards (“RTS”) specifying the requirements on strong customer authentication and common and secure communication under PSD2 published on 12 August 2016.
Accenture provides a range of consulting, technology and outsourcing services supporting technical infrastructure of payments and cards processes to various retailers, banks and payment processors. We are helping banks to build their open banking capabilities and innovative business models. Through this work, we have experience of the trends and hot topics in the payments industry in Europe and globally, and their impact on organisations and consumers. Open banking, open APIs, e- and mCommerce including payments are one of these issues and, as such, we welcome the opportunity to answer the EBA Consultation Paper on future Regulatory Technical Standards on strong customer authentication and common and secure communication under PSD2.
Our response starts with a short discussion on the fast changing payments landscape to set the context for our answers to the 10 consultation questions which follow.
2. Context
The EBA acknowledges in the Consultation Paper that it has made difficult trade-offs between competing demands – for example between security and innovation, between innovation and the risk of fragmentation and between authentication and user-friendliness.
In making these trade-offs, and in defining the final RTS the following factors are important:
o The balance between high security standards and user convenience, in particular the facilitation of frictionless payments
o The impact on competition, not just competition between banks, but also between new entrants, FinTech and non-bank PSPs
o The digital environment in which consumers operate, the digital devices they utilise and the network connectivity that is available to them
o The different needs and business models (including new business models) of merchants, which are diverse and changing with innovation and consumer expectations.
Accenture believes that frictionless payments are important to the consumer experience in the digital world and to the adoption of digital services that depend on them. Payments that are easy and convenient allow consumers to enjoy the services they are paying for without detraction, which in turn helps adoption and growth of those services. Evidence for the importance of frictionless payments includes Uber (card-on-file), Starbucks (mobile payments) and Amazon (One-Click). RTS should facilitate frictionless payments appropriately to support the growth of the digital economy.
In the past decade, much of the innovation in the digital world has come from FinTechs, new entrants and new business models – Google, Amazon, Facebook, Instagram, and Twitter are some examples. It follows therefore that FinTechs and new entrants are creating a new competitive environment for the payments landscape and for banks, which have a positive effect on consumers and the economy. The RTS therefore should address the needs of both established PSPs and new entrants in order to enable competition.
The digital environment in which consumers operate is also a major consideration, in particular because the environment is not uniform, and varies geographically and demographically. This environment is multi-channel – online, mobile, POS, machine-to-machine, and uses different forms of network connectivity (internet, wifi, broadband, GPS, Bluetooth, NFC, GPRS etc). Multiple combinations of technologies are involved and not all are available everywhere the customer acts in his everyday life, e.g. wifi coverage, mobile reception coverage, or suited to their lifestyle e.g. smartphone and device usage. The RTS cannot predict these combinations, but they should also be careful to avoid making assumptions that consumers have, or want, uniform access to all technologies, all the time, in all places.
Finally, digital drives new business models and new digital businesses that cannot always be predicted. This is a challenge for the RTS as they impact businesses and business models that do not yet even exist. The PSD2 itself exists because it addresses a digital environment that did not exist when the original PSD was drafted ten years ago. Therefore it is important that the RTS do not unintentionally restrict the development of new businesses and their business models. This means the RTS needs to be flexible to allow AISPs, PISPs and ASPSPs, Fintech companies and other PSPs to operate within their own risk parameters and take their own risk decisions when it comes to fraud detection or exemptions from strong customer authentication. For example, in the cards world, ecommerce merchants often decide to turn off the “Verified-by” (3D-Secure) function. This increases their fraud risk and shifts liability to them, but it is a choice they make to reduce friction at checkout to increase completed sales.
These points set the context for our answers to this question Q1 and to the other nine questions that follow:
The requirements in Chapter 1 on authentication methods and the independency of channels should be defined to allow for a balance between strong security requirements and user convenience and allow TPPs (such as FinTechs) to develop new innovative business models. In particular, these can depend on payments being frictionless – easy and convenient for consumers. TPPs can rely on the existing authentication methods of the ASPSP (Article 97.5 PSD2), but the RTS needs to state clearly that while ASPSPs should be responsible for implementing authentication methods, they should also make them available to TPPs.
The independence of channels plays a vital role in a multi-channel and especially mobile ecosystem of desktops, mobile devices (smartphones, tablets, and watches etc.) and mobile applications. It is important that the authentication code is not transmitted through the same channel that the customer has initiated the authentication procedure. Two options for consideration in this context are:
• Using two separate devices – one for the initiation of the authentication procedure (e.g. smartphone) and one for the reception or generation of the authentication code (token device). This option is the most inconvenient way of implementing independence of channels. The user would need to carry two devices to make payments online or at POS.
• Using one device for the initiation of the authentication procedure and the reception of the authentication code (e.g. authentication code initiated via a web browser on the smartphone, with the authentication code received via a mobile application on the same smartphone device). In our view, this option needs more attention and needs to be promoted in the RTS as the best way forward. Therefore, there should be minimum requirements defined for the technical separation of the different authentication elements (device’s operating system and the mobile application receiving the authentication code on the same device). It needs to be ensured that innovative authentication elements and methods should not be discriminated against.
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
• Article 2.2 states that technological solutions shall be in place to ensure confidentiality, authenticity and integrity through all phases of the authentication procedure. The RTS shall consider the ever-growing usage of mobile in the payments ecosystem and should be balancing the security aspects and the customer experience.• It is unclear whether this would put in place a restriction on the use of the mobile device as both the payment initiator channel and the authentication code recipient channel.
• Clarification on when the segregation of channel, app, mobile, device are acceptable is required in the RTS (considered against wider security and other trade-offs).
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
• Articles 3, 4 and 5 of the draft RTS cover the relevant threats related to the protection of authentication elements. However, it is important that the measures to increase the resistance of authentication methods should not dramatically reduce a frictionless user experience using a TPP service. A reasonable balance between high standard security requirements and frictionless usage is critical.• Clarification is required on which biometric technologies are to be supported as minimum requirements (e.g. fingerprints, face and voice recognition, iris scan) and the security requirements on storage of this sensitive data by the ASPSP.
• Threats related to the reply of the authentication information in the possession and inherence category are not specified. This threat is more hazardous to inherence based authentication (if compromised) considering the inherence related factors cannot be altered easily (for e.g. finger print pattern/iris scan), if attackers find ways to reply with this information during the authentication phase.
• It would be beneficial to refer to the inherence capturing mechanism/channel in the RTS.
• Even though the topic behavioural data analysis is not part of the authentication elements, we note that “behavioural data” is not included in the RTS as a fraud prevention mechanism, but consider it should not be excluded. There are multiple highly innovative companies developing fraud prevention and authentication methods using behavioural data and hence help improving user convenience and experience, not least because these methods allow for continuous and “invisible” authentication of the user.
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?
The exemptions from the application of Article 97 (PSD2) on strong customer authentication in Chapter 2 of the RTS supports increased convenience and a better experience for the user. Payments and open banking services occur in a multi-channel ecosystem – e.g. eCommerce, mCommerce, POS (merchants) – and require frictionless payment and account information servicing processes.• However, there are multiple questions that require consideration:
o Is the ASPSP the only entity that is permitted to verify exemptions? TPPs (AISP, PISP, PSP) should be granted with the possibility to overrule the exemption rules if requested by the user.
o Is there a time limit for the validity of the “cumulative amount” (150 EUR for contactless through a PSP and 100 EUR for credit transfers through a PISP) or is it valid for an unlimited timeframe?
o In order to make online payments initiated through TPPs successful on the market, the exemption amount of 10 EUR for a credit transfer is not sufficient since the average order value in eCommerce and POS is higher than 50 EUR. An increased exemption amount up to 50 EUR should be considered to ensure a frictionless user experience (see UK average debit card value of £43.43, http://uk.creditcards.com/credit-card-news/uk-britain-credit-debit-card-statistics-international.php). Alternatively, it should be thought of not to define any fixed exemption amounts and leave it configurable for the PSP and the user to determine
o In case of fraud, TPPs and ASPSPs must be in a position to prove if all security measures were applied on a transaction. If the TPP or ASPSP applied an exemption for a transaction that proved fraudulent, the TPP or ASPSP need to compensate the losses. It is important that the RTS enables them to decide if they allow exemptions or not. Otherwise it is not clear which party covers the risk of fraud in the context of an exemption. The RTS should enable TPPs and ASPSPs to operate within their own risk parameters and make their own risk decisions. For example, in the cards world, ecommerce merchants often decide to turn off the “Verified-by” (3D-Secure) function. This increases their fraud risk and shifts liability to them, but it is a choice they make to reduce friction at checkout to increase completed sales.
• Another aspect that needs to be detailed out is the exemption rules for AISPs in Article 8.1a. The RTS states that the AISP shall not be exempted where the payer accesses the information of its payment account online, or the consolidated information on other payment accounts held, for the first time or later than one month after the last day in which strong customer authentication was applied. Where there are multiple information requests in a short time period, the user will not be asked for strong customer authentication and not to enter user credentials and authentication code each time data is requested. In order to enable TPPs such as FinTechs and PSPs to develop successful user-friendly applications and avoid friction, there is a need for a technical mechanism and infrastructure from the ASPSP to cater for this function. Tokenisation Services could be a possible approach to permit TPPs accessing the payment account multiple times using a token without going through the entire authentication process again.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
• As stated before, exemptions from applying strong customer authentication are an integral contribution to a frictionless payment process. However, strictly defined exemptions should not be mandatory. Where a PSP applied an exemption for a fraudulent transition, the PSP would need to compensate the loss, as the liability for this unauthorised transaction shifts towards the PSP. Consideration should be given to allowing a PSPs to decide based on its own risk assessment if it allows exemptions or not. Otherwise it is not clear which party covers the risk of fraud in the context of exemptions. Uncertainty in the context of liability might prevent PSPs from applying exemptions, with an adverse impact on a frictionless payment experience. Furthermore, the exemption rules should be configurable for the user of the PSP (PISP and ASPSP).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?
• In general the requirements proposed in Chapter 3 on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials make sense. However, Article 9 Section 1c states that “secret cryptographic material related to the encryption of the credentials is stored in secure and tamper resistant devices and environments”. It is important to specify what is meant by “devices and environments” and to consider tamper resistant software in addition to hardware – especially when it comes to channel independence.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?
• In general the requirements proposed in Chapter 4 for common and secure open standards of communication for the purpose of identification, authentication, notification, and information reflect the minimum principles of open banking. ASPSPs will need to implement and provide a common and open standard interface for TPPs (PISP, AISP and PSPs issuing card-based payment instruments) and provide them with the same level of availability, including support, account information data as made available to its own online services. This is the right way forward in order to promote an open banking ecosystem.• However, the described interfaces, mechanisms and formats (ISO20022 or other industry standards) need to be specified in terms of minimum technical requirements e.g. basic mechanisms and field level information which will make it less complex to implement these interfaces at the TPP’s side. A tendency towards more harmonisation would be desirable.
• For the intended benefits of the PSD2 and ease of operations for PSPs and TPPs it would be beneficial to provide some guidance on some open standards. Without specification of these open standards there is the possibility of interoperability issues, especially for TPPs where each PSP may have different interpretation.
• Specifying standards such as OAuth 2.0 and OpenID connect, can help PSPs prepare themselves for these technologies in the PSD2 world. Obviously, as technology moves on these, standards will inevitably change or even be replaced, but it gives everyone now a common starting position, and any changes can be introduced after future consultations.
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?
• There is no reason to see any constraints. On the contrary, the usage of industry standards such as ISO20022 should be supported to increase the interoperability between PISP, AISP and ASPSP. As stated in Q7, it is necessary to specify these elements, components and message definitions in terms of clear technical specifications. ASPSPs should provide technical documentation based on the minimum requirements specified in the final RTS and help TPPs to rapidly adopt the various interfaces for its services.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 ?
• The issuance of certificates by a qualified trust service provider would provide better control in the PSD2 ecosystem and hence bring transparency to all market participants.• It would be beneficial to specify a qualified trust provider as the registration authority along with mandating security checks (such as revocation) during certificate based authentication.
• To increase certainty, the final RTS could provide greater detail on:
o the high level End-to-End certification process of a PSP, even if each member state has autonomy
o the guidelines for mandatory information required for certificate issuance
o the information of the PSP needed to be in place at the ASPSP-side to perform the authentication verification process
o the minimum technical standards to prevent service denial situation between a PSP and TPP.
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.
• In Article 22.5b, the RTS states that the AISP shall request information from designated payment accounts and associated payment transactions any time the payment service user requests such information or where the payment service user does not actively requesting such information from the ASPSP i.e.no more than 2 times a day. The proposed limit of 2 times a day for an AISP to request information from designated payment accounts should be maintained as a minimum requirement and hence be configurable by the user. The user should be granted with the permission to allow the AISP accessing the payment account multiple times a day automatically without any actions taken by the user.• In our view, the ASPSP should provide the user with an access control function in order to manage all access rights that were given to TPPs to access the payment account. This access control function should be specified in the final RTS.
• Further, availability of a real-time balance can be an important component of the consumer experience when making digital payments – it therefore follows that PISPs who are also AISPs are likely to request real-time balance information before and immediately after a payment. Therefore it is reasonable for a PISP or AISP to request account balance information with a frequency that is dependent on the consumer’s frequency of payments.