Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Security is a major issue for consumers, but convenience is also an important factor when undertaking payment transactions. The BSG is supportive of the work that the EBA is undertaking in developing the RTS and in striking a balance between the two factors.
Response to Q1:
It would be helpful to address risks and requisite controls by setting out objectives at a reasonably high level, leaving it to the regulated sector to find the appropriate means of achieving those objectives. IT security is a fast moving and rapidly evolving area that lends itself to objectives focused requirements rather than specific solutions. PSD2 text has chosen to prescribe a specific means of addressing authentication of payment transactions, and has furthermore prescribed a particular approach for adoption. This makes the elaboration of the requirements in an RTS all the more important, as they have the potential of introducing some relief by creating some space for variation and for innovation within the boundaries set by level 1 text. This would also be consistent with responses the EBA received during the consultation on the discussion paper, and the EBA’s own conclusions as set out at paragraphs 20-21 and 22 respectively of the current consultation.
We acknowledge the benefits of uniformity in payment services as well as the need for a level playing field but remind supervisors of the fast moving and rapidly evolving nature of security threats facing industry; these require an equally rapid response that is capable of mitigating such threats. There is also the risk in a homogenous solution of creating a systemic risk and a single point of failure that could be exploited by criminals.
We have therefore sought in some parts to comment on RTS provisions in a manner that seeks to increase industry’s ability to interpret and innovate solutions, setting out objectives, whilst complying with the requirements of PSD2.
On the opposite, some BSG members are of the opinion that only the regulator may set the requirements of strong customer authentication and fully support the draft RTS.
Specific comments
1. In our view, the EBA’s approach (rationale 19b) that PSD2 Article 74(2) only applies during a short-time transitional period is not supported by PSD2 text. Article 74(2) sets out a general principle of liability distribution without reference to a temporary or grandfathering type of application. The proposed interpretation would impose a new obligation on acquiring PSPs, forcing merchants to support strong customer authentication irrespective of the risk posed.
2. RTS Article 2 sets out the procedure for strong customer authentication, and provides that this should result in the creation of an authentication code, as an essential requisite of the process. This code would be unique and accepted only once by the PSP for any given PSU.
This implementation solution is one of a number of possible approaches, and industry may wish to adopt alternative implementations that are capable of meeting PSD2 SCA objectives. These could incorporate a combination of the different authentication elements of knowledge, possession and inherence, but would not necessarily result in a unique authentication code; for example, a digital signature may be generated using a combination of static authentication elements. This may be entirely sufficient for some payment account interactions that do not expose or alter sensitive payment data (such as payment card PAN, PSU address information etc.). Such approaches may be necessary as part of new and innovative payment solutions, as contemplated by Article 98(2)(e) of PSD2.
3. RTS Article 1 introduces requirements that relate to the combatting of fraud and sets out a number of controls that are required to be deployed as part of a customer authentication process. Whilst these provisions are helpful, they are intended to counter payment transaction fraud and do not easily fit within a PSU authentication requirements framework.
4. In seeking to secure the environment used to store SCA elements, the RTS sets out at Article 6(3) a number of minimum requirements that must be satisfied for multi purpose devices. PSPs will however have limited control over such devices (mobile phones and tablets etc.), and will have to manage the risk of compromise of such devices. The requirements of implementing separate trusted execution environments and seeking to ensure the device has not been compromised are reasonable objectives, but are very difficult to fulfil as mandates. We would suggest these are set out as advisory rather than mandatory provisions.
5. Article 7 of the RTS, provides for PSPs to be subject to periodic audits of their compliance with SCA obligations and for the outcome of such audits to be made available to competent authorities. We suggest that EBA consider creating a public register confirming that PSPs have met compliance obligations, and which can be accessed by PSP customers. This would be consistent with transparency principles.
Furthermore, clarity as to the degree of “independent or segregated” is sought. In particular, consumers should not for example be required to carry multiple devices to complete authentication. This would be particularly cumbersome for example for consumers who are away from home.
RTS Article 2(3) sets out a use case in relation to the authorization of funds on a credit card, setting a maximum amount. The provisions states that the authorization code would apply to that maximum amount. Given the evolution of payment instruments, it would be helpful if this provisions was broadened to include other payment instruments, rather than be card specific.
This was assessed as a detriment (Rationale paragraph 53) that would distort the competitive playing field and was sufficiently significant as to justify the exclusion of a risk based transaction analysis application of the SCA from the RTS altogether.
It is however reasonable to expect that a risk-based application of regulatory obligations will necessarily be subjective. Indeed part of the benefit of the risk based approach may be the degree of subjectivity it affords and therefore the likelihood that security controls will be focused where they are most required. It involves a delegation of responsibility by the regulator to the firm, and consequently there will be variation in interpretation, but also a more detailed understanding of the risks posed. This is accepted in other parts of the regulated environment including that of risk based supervision and risk based anti-money laundering compliance. It is also implied in Recital 91 of PSD2 which places the responsibility for establishing a proportionate security environment on the PSP.
Competition may play a positive role in favouring those providers that deliver the best combination of customer utility and security. The balance is better reached through a more open approach that enables PSPs to develop systems and to deploy innovative technology solutions that facilitates secure payment transactions without significantly impacting the customer experience. Enabling a transaction risk based analysis exemption is a prerequisite for such solutions.
Some BSG members took an opposing position, seeking simplicity for consumers, and consistency in the customer experience, agreeing with he EBA’s analysis set out in the rationale section at paragraph 53 of the consultation paper.
Other BSG members suggest that the EBA reconsider its decision not to adopt exemptions from SCA based on transaction risk analysis and to allow the sector which includes some of the most innovative technology providers worldwide to continue to offer solutions that balance security with customer access.
This risk based approach should be established by the ASPSPs, following Rationale 19 which states that without contractual agreement between PSPs, the SCA Procedure remains fully in the sphere of competence of the ASPSP. We suggest to also address this issue in the RTS.
2. The exemption for low value remote payments has been set so that single transactions are limited to EUR 10 and cumulative values of EUR 100, at which point SCA will be triggered (RTS Article 8(2)(d)). It should be remembered that even without SCA, such transactions would need to be authenticated and will involve an authorization process. Requiring users to undergo SCA for payments at a low threshold will have an impact on the time taken to complete payment, the cumulative cost of processing and the customer experience. It may be preferable therefore to increase this limit to EUR 50 for a single transaction in line with the contactless payment threshold (RTS Article 8(1)(b)), enabling low value payment to take place more rapidly and with less user friction.
This will also help with consumer education, as the limits both online and off line would be the same. It is noted that PSD2 Article 74(2) places the entire liability in the case of unauthorized transactions that do not involve SCA with the PSP and not with the customer. There will therefore be no consumer detriment in increasing this allowance. There may also be issues if the transaction which triggers the SCA is a contactless transaction where it is not possible for the customer to authorize the transaction – such as one on a mass transit network.
Some BSG members took the view that consumers were sufficiently familiar with SCA as not to warrant an increase in the threshold.
Other BSG members expressed their preference for an increase, and the exemption threshold may also benefit from more frequent updates or flexibility depending on market need and applicable security risks. It may therefore be worth considering an annual review of these thresholds by the EBA with a view to calibrating the values in response to market needs.
3. The exemption for payer whitelists set out at Article 8(2)(a) of the draft RTS refers to payer creation of the whitelist. It is unclear whether such specification of a white list would be explicit, or whether the PSP could generate the white list based on previous transactions. We would suggest a PSP-assisted approach, with the explicit consent of the user (based on a list previously created), would remove much friction from the process and provide a more effective customer experience.
4. Confirmation is sought of the application of Article 74(2) of PSD2 allocating the risk of loss where SCA is not applied to the ASPSP, where this was not applied despite there being no valid exemption available.
Some BSG members agree with the various exemptions, in particular with the idea developed in note 52 on the need to maintain the high level of security provided by the chip and pin technology.
1. The requirement to store secret cryptographic material in tamper resistance devices and environments (RTS Article 9(1)(c)) could be broadened to allow for other means of protecting such material. This could for example include key fragmentation and storage in separate systems and other processing that does not involve tamper-resistant hardware.
2. The provisions for renewal and replacement of existing security credentials at Article 14 of the RTS provide that these should be the same as those of the creation, association with the PSU and delivery of new credentials, set out at Articles 11-13 of the RTS. It may be overly onerous to require PSPs to implement identical procedures, particularly where the circumstances pose a lower level of risk.
It will continue to be important for PISPs and AISPs to be able to rely on the authentication procedures of the ASPSPs as set out under PSD2 and under Article 19(2) of the RTS. This core capability should not be compromised by separate provisions for the protection of confidentiality and integrity of PSCs, nor interpretations that seek to dilute such PISP and AISP rights.
Some BSG members remind that Article 10 creates a specific obligation when the transaction is initiated through the payee, which is logical. But the restriction to card-based payment transaction is incoherent. First, there is nothing that justifies a specific rule regarding cards. Second, direct debit is also a transaction initiated by the payee. Why does the article do not cover this situation? Therefore, in the view of these members, the sentence “in the context of a card based transaction” should be deleted.
There is some concern regarding the requirement for PIS and AIS service providers to ensure that the processing and routing of PSCs is undertaken within an environment that is compliant with ISO 27001 Information Security Management Standard. This is because the nature of this standard requires compliance by the business as a whole, rather than being specific to a particular interaction or system. It is furthermore not a trivial or inexpensive exercise to undertake, requiring organizational wide security controls and audits on a three-year frequency, that must be undertaken by an external certified auditor.
The requirement is not currently mandated for credit, payment or electronic money institutions and nor is it required as part of authorization obligations for PIS or AIS providers. There is a risk that this could be regarded as exceeding the mandate of PSD2 and introducing additional authorization obligations that are not justified by the mandate of the RTS.
As the expectation is for most if not all PSPs to engage in some form of PIS or AIS activity, this would amount to the introduction of ISO 27001 as a mandated standard for the entire PSP industry, with the consequent cost and effort that this will entail. We caution over this approach and consider that it should be replaced with a generic reference to commonly accepted security standards.
Finally, it seems that we are still lacking a clear definition of responsibilities and procedures as well as the body or authority needed to solve possible disputes and liabilities without having to resort to legal proceedings.
We also note that a number of additional specifications may need to be detailed such as the requirements for registration and certificate management processes, for both the Trust Service Provider (Certification Authority) and the PSP.
It may be possible to address this issue by specifying different expectations for different types of calls on an APSP system. Calls that seek to download bulk information may be limited to a low daily number, while calls that seek to establish whether the records have changed and seek a record of the incremental change may be less intrusive and could be serviced far more frequently.
Better still would be the development of systems – and the inclusion of provisions in the RTS, for systems that proactively update registered applications when changes occur, to avoid unnecessary system calls.
There also another issue related to the interpretation of what “actively requesting” means and the difficulty of identifying which TPP’s requests are originated by a direct PSU service request rather than automated system-generated requests. These issues may limit the effectiveness of the proposed 2-tier AISP service approach and impact all AISP service requests.
Consequently, RTS could seek to differentiate individual requests initiated by PSUs from bulk automated service requests generated at specific times. The latter may be legitimate, but their use may have to be demonstrated by the use-case of the application in question. Bulk authorisation of such requests should not be used as a means to circumvent the RTS requirement without a genuine user need to access the data that is requested.
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?
General commentsSecurity is a major issue for consumers, but convenience is also an important factor when undertaking payment transactions. The BSG is supportive of the work that the EBA is undertaking in developing the RTS and in striking a balance between the two factors.
Response to Q1:
It would be helpful to address risks and requisite controls by setting out objectives at a reasonably high level, leaving it to the regulated sector to find the appropriate means of achieving those objectives. IT security is a fast moving and rapidly evolving area that lends itself to objectives focused requirements rather than specific solutions. PSD2 text has chosen to prescribe a specific means of addressing authentication of payment transactions, and has furthermore prescribed a particular approach for adoption. This makes the elaboration of the requirements in an RTS all the more important, as they have the potential of introducing some relief by creating some space for variation and for innovation within the boundaries set by level 1 text. This would also be consistent with responses the EBA received during the consultation on the discussion paper, and the EBA’s own conclusions as set out at paragraphs 20-21 and 22 respectively of the current consultation.
We acknowledge the benefits of uniformity in payment services as well as the need for a level playing field but remind supervisors of the fast moving and rapidly evolving nature of security threats facing industry; these require an equally rapid response that is capable of mitigating such threats. There is also the risk in a homogenous solution of creating a systemic risk and a single point of failure that could be exploited by criminals.
We have therefore sought in some parts to comment on RTS provisions in a manner that seeks to increase industry’s ability to interpret and innovate solutions, setting out objectives, whilst complying with the requirements of PSD2.
On the opposite, some BSG members are of the opinion that only the regulator may set the requirements of strong customer authentication and fully support the draft RTS.
Specific comments
1. In our view, the EBA’s approach (rationale 19b) that PSD2 Article 74(2) only applies during a short-time transitional period is not supported by PSD2 text. Article 74(2) sets out a general principle of liability distribution without reference to a temporary or grandfathering type of application. The proposed interpretation would impose a new obligation on acquiring PSPs, forcing merchants to support strong customer authentication irrespective of the risk posed.
2. RTS Article 2 sets out the procedure for strong customer authentication, and provides that this should result in the creation of an authentication code, as an essential requisite of the process. This code would be unique and accepted only once by the PSP for any given PSU.
This implementation solution is one of a number of possible approaches, and industry may wish to adopt alternative implementations that are capable of meeting PSD2 SCA objectives. These could incorporate a combination of the different authentication elements of knowledge, possession and inherence, but would not necessarily result in a unique authentication code; for example, a digital signature may be generated using a combination of static authentication elements. This may be entirely sufficient for some payment account interactions that do not expose or alter sensitive payment data (such as payment card PAN, PSU address information etc.). Such approaches may be necessary as part of new and innovative payment solutions, as contemplated by Article 98(2)(e) of PSD2.
3. RTS Article 1 introduces requirements that relate to the combatting of fraud and sets out a number of controls that are required to be deployed as part of a customer authentication process. Whilst these provisions are helpful, they are intended to counter payment transaction fraud and do not easily fit within a PSU authentication requirements framework.
4. In seeking to secure the environment used to store SCA elements, the RTS sets out at Article 6(3) a number of minimum requirements that must be satisfied for multi purpose devices. PSPs will however have limited control over such devices (mobile phones and tablets etc.), and will have to manage the risk of compromise of such devices. The requirements of implementing separate trusted execution environments and seeking to ensure the device has not been compromised are reasonable objectives, but are very difficult to fulfil as mandates. We would suggest these are set out as advisory rather than mandatory provisions.
5. Article 7 of the RTS, provides for PSPs to be subject to periodic audits of their compliance with SCA obligations and for the outcome of such audits to be made available to competent authorities. We suggest that EBA consider creating a public register confirming that PSPs have met compliance obligations, and which can be accessed by PSP customers. This would be consistent with transparency principles.
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.
SCA with dynamic linking sets out requirements for the segregation of the authentication procedure from that of payment initiation. Article 2(2)(b) of the RTS requires that the channel, device or mobile application used for one is segregated from the other. This is likely to introduce additional transaction complexity which in turn may decrease user convenience and product utility. This may be at variance with the objectives of user-friendliness and accessibility that are required under Article 98(2)(e) of PSD2. Therefore, we would prefer that, instead of being an obligation, this device independence requirement would be a recommendation and ASPSPs would be given the ability to decide whether to require the use of a second authentication device or application.Furthermore, clarity as to the degree of “independent or segregated” is sought. In particular, consumers should not for example be required to carry multiple devices to complete authentication. This would be particularly cumbersome for example for consumers who are away from home.
RTS Article 2(3) sets out a use case in relation to the authorization of funds on a credit card, setting a maximum amount. The provisions states that the authorization code would apply to that maximum amount. Given the evolution of payment instruments, it would be helpful if this provisions was broadened to include other payment instruments, rather than be card specific.
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?
The provisions setting out characteristics in relation to the knowledge authentication elements at Article 3(1) could be set out as examples, enabling PSPs to deploy password policies that are best suited for the particular implementation. The requirement for ‘non repeatable characters’ is of particular concern if it were to be given its ordinary meaning of prohibiting re-use of the same character in any given password. This is likely to frustrate users who may be unable to create memorable passwords and pass phrases, and may ultimately compromise the confidentiality of the password if users find they have to record these in writing.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?
1. The EBA has sought to balance requirements for adopting a risk based approach that facilitates access to payment products as set out at Recital 96, Articles 98(2)(a) and 98(2)(e) of PSD2, with those of ensuring fair competition amongst all PSPSs as set out at Article 98(2)(c). This resulted in the EBA excluding provisions for a risk based application of SCA based on transaction analysis, as no single means of ensuring equivalent application could be developed. In other words, it was likely that different providers would develop their own risk based analytical processes that would result in a varied application of the exemption across the population of PSPs.This was assessed as a detriment (Rationale paragraph 53) that would distort the competitive playing field and was sufficiently significant as to justify the exclusion of a risk based transaction analysis application of the SCA from the RTS altogether.
It is however reasonable to expect that a risk-based application of regulatory obligations will necessarily be subjective. Indeed part of the benefit of the risk based approach may be the degree of subjectivity it affords and therefore the likelihood that security controls will be focused where they are most required. It involves a delegation of responsibility by the regulator to the firm, and consequently there will be variation in interpretation, but also a more detailed understanding of the risks posed. This is accepted in other parts of the regulated environment including that of risk based supervision and risk based anti-money laundering compliance. It is also implied in Recital 91 of PSD2 which places the responsibility for establishing a proportionate security environment on the PSP.
Competition may play a positive role in favouring those providers that deliver the best combination of customer utility and security. The balance is better reached through a more open approach that enables PSPs to develop systems and to deploy innovative technology solutions that facilitates secure payment transactions without significantly impacting the customer experience. Enabling a transaction risk based analysis exemption is a prerequisite for such solutions.
Some BSG members took an opposing position, seeking simplicity for consumers, and consistency in the customer experience, agreeing with he EBA’s analysis set out in the rationale section at paragraph 53 of the consultation paper.
Other BSG members suggest that the EBA reconsider its decision not to adopt exemptions from SCA based on transaction risk analysis and to allow the sector which includes some of the most innovative technology providers worldwide to continue to offer solutions that balance security with customer access.
This risk based approach should be established by the ASPSPs, following Rationale 19 which states that without contractual agreement between PSPs, the SCA Procedure remains fully in the sphere of competence of the ASPSP. We suggest to also address this issue in the RTS.
2. The exemption for low value remote payments has been set so that single transactions are limited to EUR 10 and cumulative values of EUR 100, at which point SCA will be triggered (RTS Article 8(2)(d)). It should be remembered that even without SCA, such transactions would need to be authenticated and will involve an authorization process. Requiring users to undergo SCA for payments at a low threshold will have an impact on the time taken to complete payment, the cumulative cost of processing and the customer experience. It may be preferable therefore to increase this limit to EUR 50 for a single transaction in line with the contactless payment threshold (RTS Article 8(1)(b)), enabling low value payment to take place more rapidly and with less user friction.
This will also help with consumer education, as the limits both online and off line would be the same. It is noted that PSD2 Article 74(2) places the entire liability in the case of unauthorized transactions that do not involve SCA with the PSP and not with the customer. There will therefore be no consumer detriment in increasing this allowance. There may also be issues if the transaction which triggers the SCA is a contactless transaction where it is not possible for the customer to authorize the transaction – such as one on a mass transit network.
Some BSG members took the view that consumers were sufficiently familiar with SCA as not to warrant an increase in the threshold.
Other BSG members expressed their preference for an increase, and the exemption threshold may also benefit from more frequent updates or flexibility depending on market need and applicable security risks. It may therefore be worth considering an annual review of these thresholds by the EBA with a view to calibrating the values in response to market needs.
3. The exemption for payer whitelists set out at Article 8(2)(a) of the draft RTS refers to payer creation of the whitelist. It is unclear whether such specification of a white list would be explicit, or whether the PSP could generate the white list based on previous transactions. We would suggest a PSP-assisted approach, with the explicit consent of the user (based on a list previously created), would remove much friction from the process and provide a more effective customer experience.
4. Confirmation is sought of the application of Article 74(2) of PSD2 allocating the risk of loss where SCA is not applied to the ASPSP, where this was not applied despite there being no valid exemption available.
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?
There is a balance being struck between an ASPSP having the ability to choose whether to apply SCA in a given transaction, taking other risk factors into consideration, and the application of a consistent SCA framework. There needs to be some flexibility, but regulators will need to ensure that ASPSPs do not discriminate against transactions originating with other PSPs -(including for example PISPs), by making the payment process more complex. This could be set out in similar terms to the non discriminatory requirements for service levels set out at Recital 13 of PSD2 in relation to communication interface utility. This should not however be construed as a reason to limit the ASPSP having the ability to apply a transaction risk based decision to individual transactions.Some BSG members agree with the various exemptions, in particular with the idea developed in note 52 on the need to maintain the high level of security provided by the chip and pin technology.
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?
A principles-based approach to measures that protect the creation, delivery, activation, renewal and destruction of credentials is welcome. In this context we note the following:1. The requirement to store secret cryptographic material in tamper resistance devices and environments (RTS Article 9(1)(c)) could be broadened to allow for other means of protecting such material. This could for example include key fragmentation and storage in separate systems and other processing that does not involve tamper-resistant hardware.
2. The provisions for renewal and replacement of existing security credentials at Article 14 of the RTS provide that these should be the same as those of the creation, association with the PSU and delivery of new credentials, set out at Articles 11-13 of the RTS. It may be overly onerous to require PSPs to implement identical procedures, particularly where the circumstances pose a lower level of risk.
It will continue to be important for PISPs and AISPs to be able to rely on the authentication procedures of the ASPSPs as set out under PSD2 and under Article 19(2) of the RTS. This core capability should not be compromised by separate provisions for the protection of confidentiality and integrity of PSCs, nor interpretations that seek to dilute such PISP and AISP rights.
Some BSG members remind that Article 10 creates a specific obligation when the transaction is initiated through the payee, which is logical. But the restriction to card-based payment transaction is incoherent. First, there is nothing that justifies a specific rule regarding cards. Second, direct debit is also a transaction initiated by the payee. Why does the article do not cover this situation? Therefore, in the view of these members, the sentence “in the context of a card based transaction” should be deleted.
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?
The EBA has generally taken a measured approach in specifying open and secure standards of communication between PSPs. We welcome the reference to standards of communication developed by international or European standardisation organisations. However, in order to achieve pan-European harmonization and interoperability of ASPSPs access solutions, a clear description of what qualifies, as an international or European standardisation organisation is needed.There is some concern regarding the requirement for PIS and AIS service providers to ensure that the processing and routing of PSCs is undertaken within an environment that is compliant with ISO 27001 Information Security Management Standard. This is because the nature of this standard requires compliance by the business as a whole, rather than being specific to a particular interaction or system. It is furthermore not a trivial or inexpensive exercise to undertake, requiring organizational wide security controls and audits on a three-year frequency, that must be undertaken by an external certified auditor.
The requirement is not currently mandated for credit, payment or electronic money institutions and nor is it required as part of authorization obligations for PIS or AIS providers. There is a risk that this could be regarded as exceeding the mandate of PSD2 and introducing additional authorization obligations that are not justified by the mandate of the RTS.
As the expectation is for most if not all PSPs to engage in some form of PIS or AIS activity, this would amount to the introduction of ISO 27001 as a mandated standard for the entire PSP industry, with the consequent cost and effort that this will entail. We caution over this approach and consider that it should be replaced with a generic reference to commonly accepted security standards.
Finally, it seems that we are still lacking a clear definition of responsibilities and procedures as well as the body or authority needed to solve possible disputes and liabilities without having to resort to legal proceedings.
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 benefit in a harmonized approach to messaging between PSPs, and whilst ISO20022 is generally used in card and ACH networks, it is not common in the online e-commerce and FinTech space. It would be preferable therefore if a specific messaging standard was not specified in the RTS, and it was left to industry to develop a common preferred approach.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 that e-IDAS Qualified Trust Service providers may be used to issue PSP server certificates that are used to enable secure identification and authentication of PSPs. We note however that such service providers are yet to begin to offer services and there will need to be multiple providers on the market to meet the technical and commercial demands of the industry. Some contingency provisions may also be desirable to ensure full service availability.We also note that a number of additional specifications may need to be detailed such as the requirements for registration and certificate management processes, for both the Trust Service Provider (Certification Authority) and the PSP.
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.
The need to avoid excessive calls on the systems of ASPSPs is reasonable and limiting access is also a reasonable approach. Limiting access to twice daily is likely however to be limiting for many existing and future applications. Many of these depend on account data being up to date and will likely resort to the user requesting an update.It may be possible to address this issue by specifying different expectations for different types of calls on an APSP system. Calls that seek to download bulk information may be limited to a low daily number, while calls that seek to establish whether the records have changed and seek a record of the incremental change may be less intrusive and could be serviced far more frequently.
Better still would be the development of systems – and the inclusion of provisions in the RTS, for systems that proactively update registered applications when changes occur, to avoid unnecessary system calls.
There also another issue related to the interpretation of what “actively requesting” means and the difficulty of identifying which TPP’s requests are originated by a direct PSU service request rather than automated system-generated requests. These issues may limit the effectiveness of the proposed 2-tier AISP service approach and impact all AISP service requests.
Consequently, RTS could seek to differentiate individual requests initiated by PSUs from bulk automated service requests generated at specific times. The latter may be legitimate, but their use may have to be demonstrated by the use-case of the application in question. Bulk authorisation of such requests should not be used as a means to circumvent the RTS requirement without a genuine user need to access the data that is requested.