Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
Rationale 19.a:
The SBA supports the conclusion by EBA.
Rationale 19.b:
SBA fully supports the conclusion made by EBA that PSD2 does not allow for any exemptions on the acquiring/merchant side from the requirement to support strong customer authentication for all card payments, once the RTS is in force. We also agree that the liability shift described in the second sentence in article 74(2) therefore has a larger relevance for the period in between when the PSD2 is in force and until the RTS comes in force, i.e. there are large number of transactions for which this liability shift is applicable.
However, we would like to point out that the liability shift in 74 (2) is still valid also after the point in time when the RTS comes in force, in cases where the merchant/acquirer still fails to comply with the law (PSD2 and RTS) in supporting strong authentication. In such cases there will still be a value in itself to have this clause clearly laying the liability on the acquirer, despite the fact that the acquirer is in breach of the law. This liability shift should apply regardless if the issuer has managed to decline in the authorisation the non-strong customer authentication-transaction, or not.
It is important to identify if the payee or the payment service provider of the payee fails to accept strong customer authentication. The RTS does not cover how this should be done from the payee’s side or how the ASPSPs could be able to monitor it. Clarification on the subject would be appreciated.
Article 1:
For example article 1 deals with authentication, but in article 1.3.e authorisation is suddenly used. The Article seems to confuse authentication (the customer proving their identity) with authorisation (the customer approving the execution, for example a payment). The difference between these concepts and how they are used is an important issue but there is no clear distinction between “authentication” and “authorisation”. It would be valuable if there were. Please rephrase/clarify the meaning with the respective word.
With reference to the above mentioned mix between the different concepts of authentication and authorisation, it is important to understand that the ability for the ASPSP to authorise each transaction is still needed and is not exempted.
Regardless whether authorisation is outside the mandate of the PSD2 or not the article’s wording “shall take into account” should be changed to “may take into account”.
The term authentication code" is used in a way which is difficult to interpret, see for example article 1 and rationale 22, 24, 25. It seems as if the term can mean a variety of things – for example a PIN-code, a code delivered to a PIS or a code generated by different elements during the process of strong customer authentication – which makes it difficult to know if you are compliant.
Article 1.1:
As we understand it POS transactions are in scope of the RTS and authentication codes are not technically applicable to magnetic stripe transactions. Will magnetic stripe card transactions still be allowed under the RTS?
Article 1.2:
The SBA proposes that the following sentence is changed from:
“security features, including, but not limited to, algorithm, specifications, length, information entropy and expiration time, ensuring that:”
to:
“security features ensuring that:”
The argument for the change is that it becomes more technically neutral.
Article 1.3:
The SBA proposes that EBA refrains from mentioning https and TLS.
The argument for the change is that they are not future proof.
Article 1.3.b:
In some situations, feedback to the payer on what went wrong can be helpful. For example if the payer enters the wrong PIN for a card transaction, it is common practice to display “Wrong PIN” in the terminal. Avoiding to show “wrong password” is an important principle for a one-factor solution but has limited security benefits for a strong customer authentication solution, in particular one that has 1.3.c implemented correctly. The article should therefore be revised.
Article 2.1.b:
The article does note state a clear correlation between the payee and the issued transaction that can be used with regard to the validity (non-repudiation). This can be achieved by using a digital signature mechanism for the electronic payment transaction.
Article 6.3:
In relation to the mitigating measures, as stated before, the SBA considers that it is better to list some examples that may be used, instead of the mechanism that shall be used. Therefore, the following changes to the RTS are proposed:
“For the purposes of paragraph 2, the mitigating measures may include, but not be limited to…..”
Article 6.3.a:
The SBA suggests not to use the term ‘trusted execution environment’, since this is specific defined term (with capital letters: Trusted Execution Environment) in the Global Platform standard. This reference is too specific. The SBA suggests to replace this term by “a segregated secure environment”.
General Comments:
The RTS describes that the aim is to be technology neutral and allow the PSP to develop their solutions and change them as needed for security reasons, cf. p 22. At the same time there are several detailed requirements that do not fit exactly to all technical solutions. In some cases, there are examples of technologies that have a higher security without these details. It would be better to focus more on the goals rather than the means."
Rationale 26:
Rationale 26 is important as there are many techniques besides those mentioned in the rationale to create a secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app. We have previously stated some of them in our response to EBA’s Discussion Paper in February 2016 (please refer to answers to question no. 6 and 12) and they are still valid.
Additionally, the list of exemptions should not be an exhaustive list. The ASPSP must be free to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may prevent future innovations in fraud prevention analysis that are to be expected in this dynamic and changing environment. This means that the ASPSP must have the possibility to apply strong customer authentication even though formally exceptions would apply.
We strongly suggest that a digital signature should be used for credit transfers except for low value payments specified as exemptions.
Rationale 41:
The SBA welcomes the clarification made by EBA on the issue of whether exemptions from strong customer authentication could be possible also on the payee/acquiring side, thereby depriving the payer PSP/issuer the option to decide on if strong customer authentication should be used or not. The SBA welcomes the conclusion made by EBA, which will improve customer protection, reduce fraud levels as well as further enhance innovation in customer-friendly strong customer authentication methods.
Article 8.1.a.ii:
The ASPSPs want freedom of choice on when to perform exemptions from strong customer authentication.
For example, if there are indications that the credentials have been compromised (based on transaction analysis, identity theft, malware etc.) the ASPSPs need to be able to require strong customer authentication more often than every 30th day. The reason for this is consumer protection and that the ASPSP must decide on the frequency to verify that the customer is active and that the ASPSPs are responsible to verify issued credentials.
Article.8.1.b:
The SBA suggests that the word “contactless” should be deleted. The RTS in general and the exemptions from strong customer authentication should ensure technological neutrality, which EBA states in rationale 50. This principle should be upheld also for low value payments at POS terminals.
EBA states that only contactless electronic payment transactions should be subject to a low value exemption from strong customer authentication in order to preserve the high level of security provided by “chip & pin”. This reasoning is not logical - contact without PIN transactions cannot be considered less safe than contactless without PIN, on the contrary they are safer.
SBA would like to highlight that some of the major card schemes operating in Europe allow for “contact” payment transactions without PIN for small amounts (e.g. vending machines) and also for larger amounts (e.g. parking/tolls). In several cases, such as unattended parking terminals, exemptions on the PIN requirement are also done for security reasons, i.e. in order for the PIN not to be compromised by usage in a physical environment with high visibility.
Therefore, SBA’s view is that the exemption from strong customer authentication defined in article 8 (b) must be extended to also cover “contact” electronic payment transactions on the condition that the payment instrument used can be securely authenticated, i.e. the word “contactless” should be removed in Article 8.
Article 8.2.b:
The SBA is of the opinion that recurring card payments should enjoy the same exemption as recurring credit transfers, as pointed out in comment to Rationale 17, i.e. paragraph 2 in Article 8 should be updated accordingly:
“(b) the payer initiates online a series of credit transfers or card-based payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of credit transfers or card-based payments for the first time or amends the series of credit transfers.”
The SBA understands that the application of the exemptions is optional for the payer’s PSP (the issuer in a card context). Preventing the implementation of stronger security would be against all principles of rationality. ASPSPs take risks through liabilities and may be limited by regulations towards not taking too high risks. But regulations should never refrain ASPSPs from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reactions instead of proper risk-based reactions, should ASPSPs be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud). Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict requirements.
Furthermore, the idea of allowing exemptions from the requirement on strong customer authentication, is to allow the possibility to make payment initiation more convenient for the payers. The underlying assumption is that strong customer authentication creates a hustle or at least a slower payment initiation. With the escalating innovation in customer authentication methods and technology, this is no longer the case, and will probably be so even less in the future. Many times these new strong authentication methods are more customer-friendly and convenient, than many current weak authentication methods like e.g. static passwords. For payment solutions where there is today only a strong customer authentication method offered for all transactions perceived as convenient by the users, there is no need to introduce another weak customer authentication method, that would at the same time be less customer-friendly.
Article 8.1.a.ii:
It is stated that strong customer authentication is not required for 30 days. Most online channels have a time out after a few minutes of inactivity to ensure protection of customer data. Is it really feasible to allow access without strong customer authentication for such a long period of time? Is it also feasible to allow customers through TPPs (according to the two times a day rule) access for such a long time without strong customer authentication?
The SBA finds article 8.2.a contradictive to article 2.1.b requiring signing of the amount and payee of the payment initiation. When for example a payment initiated by the PSU through a PISP is done for an e-merchant using strong customer authentication and the e-merchant is amended as a trusted beneficiary (again through strong customer authentication) should subsequent purchases (regardless of amount) at that e-merchant really be possible without using strong customer authentication? Please elaborate.
Art 17.1
The SBA considers the requirement on bilateral identification between customer and acceptance devices in need of a change or at least an explanation. The SBA’s opinion is that identification is currently done of the card to the POS terminal, no reciprocal identification of the terminal is made to the card.
Art 20.3.b
It needs to be perfectly clear that the ASPSP is aware of which parties are involved in a session or transaction. Only the name of the competent authority is not sufficient. Certain parameters in a certificate identifies the parties involved. Therefore, the SBA suggests that all parties involved in the session or transaction should be clearly displayed – both ASPSP and PIS/AIS. Customer awareness and transparency are key issues in digitalisation. Furthermore, the information should also be made available to the customer for reasons of traceability.
Article 47 (not in the RTS, related to PSD2)
Article 47 states that when a payment is initiated through a PIS the PIS shall set a payment reference and make it available to the ASPSP. The SBA assumes that this is for reasons of traceability, i.e. if a customer asks the ASPSP about the origin of a transaction according to article 46 (which contains specifics on the content of the information made available). It is important that this information is delivered in a specific format and that it follows agreed communication standards between ASPSP and PIS. Therefore, the communication in article 47 should be in scope of the RTS.
The RTS is unclear regarding the use of the term website certificates". The purpose of "website certificates" is to identify a server to a client and not a client to a server, even if the client is a server which described in point 70-77. The terms "client certificate" or "client authentication certificate" should be used when a client must identify itself to create clarity."
How will the governance model including corresponding certification process to secure that the PISP/AISP is approved according to relevant standards be constructed? What standards will apply? Will it be sufficient with ISO 27001 for PISP/AISP? Please elaborate.
Article 22.5.a:
The SBA suggests a change of the article to clarify that it is the PSU that actively is requesting such information.
..any time the payment service user actively is requesting such information,"
Article 22.5.b:
Currently, the typical customer requests data 15 times per month while third party providers request data 60 times per month. The SBA therefore suggests that automatic collection of data by AISPs without an agreed mandate with the ASPSP should not be permitted. Automatic collection has limited benefits to the PSU, it drives additional cost for the ASPSPs and decreases system performance.
If automatic data collection is introduced and executed twice per day, in spite of previous arguments, it is likely to occur at the same time each day. If this is the case it can reduce IT-system’s accessibility from which this data is requested and retrieved from. The automated data collection, should, if introduced, be as limited as possible so that the system’s performance is not negatively impacted. We cannot have an order where AIS’ service offerings result in a negative accessibility for the ASPSP´s other online services. Additionally, the AIS (and PIS) need to inform their customers clearly as to what they are consenting to and how the AIS (and PIS) intend to use the collected data.
A problem that can arise is that the consumer ends its engagement with an AIS but the AIS is still allowed to access customer data up to 30 days without the customer consenting to it (according to the 2 times a day principle). PSPs cannot control and has no knowledge whether the consumer has ended the agreement or not with the AIS.
Furthermore, a consumer protection issue is awareness. It should be made clear to the PSU which mandates the PSU has given, to whom, for which purpose and how these mandates are revoked. The ASPSPs will need to update their general conditions to regulate the responsibility between the PSU and ASPSP. Moreover, this could have potential impact on data protection regulations.
On one hand, an AIS acts only with the customer's consent and must identify themselves each time to the ASPSP and should keep the session as short as possible (see article 20-21). On the other hand the AIS should according to article 22 be able to request information not only when requested by the customer, but also two times per day. This is not consistent.
Therefore, for all of the above reasons, article 22.5.b should be deleted.
Rationale for the response:
1. Ensure customer protection
2. Session timeout similar to currently prevailing online banking standards
3. Risk for privacy and integrity issues
4. Multiple certificates likely to be required for differentiation between manual requests for account information (by PSU) and automatically initiated requests (by AISP).
Moreover, there are a lot of cases where the customer will have difficulties understanding what he/she is consenting to. Below are a couple of examples of common payment scenarios:
1. A consumer wanting a short term credit giving access to an AISP who sells the customer’s transaction history to lending providers - the transaction history subsequently sold for a 30 days period.
2. Banks want their customers to make well informed purchases based on their relevant needs and not driven by retailers’ information advantage of their customers’ online shopping behaviour.
3. If the consumer is buying a book via a PISP, the consent to initiate the purchase does not include a consent to get the account information that an AISP has the possibility to get. This type of combination of PISP/AISP should not be allowed."
We represent the member companies nationally and internationally:
1. We work closely with regulators and policymakers in Sweden and Europe
2. We establish joint rules in matters of common interest in the Swedish banking industry, such as payment infrastructure and security issues.
3. We inform the public about the banking sector.
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?
The SBA welcomes EBA’s reasoning and we recognize the information provided by EBA in the hearing 23 September that EBA has no intention to force consumers to use two devices.Rationale 19.a:
The SBA supports the conclusion by EBA.
Rationale 19.b:
SBA fully supports the conclusion made by EBA that PSD2 does not allow for any exemptions on the acquiring/merchant side from the requirement to support strong customer authentication for all card payments, once the RTS is in force. We also agree that the liability shift described in the second sentence in article 74(2) therefore has a larger relevance for the period in between when the PSD2 is in force and until the RTS comes in force, i.e. there are large number of transactions for which this liability shift is applicable.
However, we would like to point out that the liability shift in 74 (2) is still valid also after the point in time when the RTS comes in force, in cases where the merchant/acquirer still fails to comply with the law (PSD2 and RTS) in supporting strong authentication. In such cases there will still be a value in itself to have this clause clearly laying the liability on the acquirer, despite the fact that the acquirer is in breach of the law. This liability shift should apply regardless if the issuer has managed to decline in the authorisation the non-strong customer authentication-transaction, or not.
It is important to identify if the payee or the payment service provider of the payee fails to accept strong customer authentication. The RTS does not cover how this should be done from the payee’s side or how the ASPSPs could be able to monitor it. Clarification on the subject would be appreciated.
Article 1:
For example article 1 deals with authentication, but in article 1.3.e authorisation is suddenly used. The Article seems to confuse authentication (the customer proving their identity) with authorisation (the customer approving the execution, for example a payment). The difference between these concepts and how they are used is an important issue but there is no clear distinction between “authentication” and “authorisation”. It would be valuable if there were. Please rephrase/clarify the meaning with the respective word.
With reference to the above mentioned mix between the different concepts of authentication and authorisation, it is important to understand that the ability for the ASPSP to authorise each transaction is still needed and is not exempted.
Regardless whether authorisation is outside the mandate of the PSD2 or not the article’s wording “shall take into account” should be changed to “may take into account”.
The term authentication code" is used in a way which is difficult to interpret, see for example article 1 and rationale 22, 24, 25. It seems as if the term can mean a variety of things – for example a PIN-code, a code delivered to a PIS or a code generated by different elements during the process of strong customer authentication – which makes it difficult to know if you are compliant.
Article 1.1:
As we understand it POS transactions are in scope of the RTS and authentication codes are not technically applicable to magnetic stripe transactions. Will magnetic stripe card transactions still be allowed under the RTS?
Article 1.2:
The SBA proposes that the following sentence is changed from:
“security features, including, but not limited to, algorithm, specifications, length, information entropy and expiration time, ensuring that:”
to:
“security features ensuring that:”
The argument for the change is that it becomes more technically neutral.
Article 1.3:
The SBA proposes that EBA refrains from mentioning https and TLS.
The argument for the change is that they are not future proof.
Article 1.3.b:
In some situations, feedback to the payer on what went wrong can be helpful. For example if the payer enters the wrong PIN for a card transaction, it is common practice to display “Wrong PIN” in the terminal. Avoiding to show “wrong password” is an important principle for a one-factor solution but has limited security benefits for a strong customer authentication solution, in particular one that has 1.3.c implemented correctly. The article should therefore be revised.
Article 2.1.b:
The article does note state a clear correlation between the payee and the issued transaction that can be used with regard to the validity (non-repudiation). This can be achieved by using a digital signature mechanism for the electronic payment transaction.
Article 6.3:
In relation to the mitigating measures, as stated before, the SBA considers that it is better to list some examples that may be used, instead of the mechanism that shall be used. Therefore, the following changes to the RTS are proposed:
“For the purposes of paragraph 2, the mitigating measures may include, but not be limited to…..”
Article 6.3.a:
The SBA suggests not to use the term ‘trusted execution environment’, since this is specific defined term (with capital letters: Trusted Execution Environment) in the Global Platform standard. This reference is too specific. The SBA suggests to replace this term by “a segregated secure environment”.
General Comments:
The RTS describes that the aim is to be technology neutral and allow the PSP to develop their solutions and change them as needed for security reasons, cf. p 22. At the same time there are several detailed requirements that do not fit exactly to all technical solutions. In some cases, there are examples of technologies that have a higher security without these details. It would be better to focus more on the goals rather than the means."
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.
The SBA welcomes the reasoning about the flexibility offered on where and when the dynamic linking can take place. That one app triggers another app is positive for the customer experience which in turn drives an increased use of strong customer authentication by the customers, for example Swish (Swish is Sweden’s Instant payment scheme with clearing and settlement in real time).Rationale 26:
Rationale 26 is important as there are many techniques besides those mentioned in the rationale to create a secured and protected environment to display the amount and the account number of the payee, and assuring the integrity of these data towards the PSU, on a single smart phone with a single online banking app. We have previously stated some of them in our response to EBA’s Discussion Paper in February 2016 (please refer to answers to question no. 6 and 12) and they are still valid.
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 SBA considers the threats identified to be well described.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?
Contrary to EBA’s conclusion (in Rationale 54) not to propose exemptions based on a transaction-risk analysis performed by the ASPSP, the SBA does not believe that the EBA fulfils its mandate with regard to PSD2 Art. 98.3(a): exemptions based on “the level of risk involved in the service provided”, since the exemptions in the current draft RTS do not allow for a risk-based assessment / approach by the ASPSP.Additionally, the list of exemptions should not be an exhaustive list. The ASPSP must be free to apply exemptions based on its own transaction risk analysis. An exhaustive list of possible exemptions or criteria to be considered by ASPSPs for the transaction risk analysis may prevent future innovations in fraud prevention analysis that are to be expected in this dynamic and changing environment. This means that the ASPSP must have the possibility to apply strong customer authentication even though formally exceptions would apply.
We strongly suggest that a digital signature should be used for credit transfers except for low value payments specified as exemptions.
Rationale 41:
The SBA welcomes the clarification made by EBA on the issue of whether exemptions from strong customer authentication could be possible also on the payee/acquiring side, thereby depriving the payer PSP/issuer the option to decide on if strong customer authentication should be used or not. The SBA welcomes the conclusion made by EBA, which will improve customer protection, reduce fraud levels as well as further enhance innovation in customer-friendly strong customer authentication methods.
Article 8.1.a.ii:
The ASPSPs want freedom of choice on when to perform exemptions from strong customer authentication.
For example, if there are indications that the credentials have been compromised (based on transaction analysis, identity theft, malware etc.) the ASPSPs need to be able to require strong customer authentication more often than every 30th day. The reason for this is consumer protection and that the ASPSP must decide on the frequency to verify that the customer is active and that the ASPSPs are responsible to verify issued credentials.
Article.8.1.b:
The SBA suggests that the word “contactless” should be deleted. The RTS in general and the exemptions from strong customer authentication should ensure technological neutrality, which EBA states in rationale 50. This principle should be upheld also for low value payments at POS terminals.
EBA states that only contactless electronic payment transactions should be subject to a low value exemption from strong customer authentication in order to preserve the high level of security provided by “chip & pin”. This reasoning is not logical - contact without PIN transactions cannot be considered less safe than contactless without PIN, on the contrary they are safer.
SBA would like to highlight that some of the major card schemes operating in Europe allow for “contact” payment transactions without PIN for small amounts (e.g. vending machines) and also for larger amounts (e.g. parking/tolls). In several cases, such as unattended parking terminals, exemptions on the PIN requirement are also done for security reasons, i.e. in order for the PIN not to be compromised by usage in a physical environment with high visibility.
Therefore, SBA’s view is that the exemption from strong customer authentication defined in article 8 (b) must be extended to also cover “contact” electronic payment transactions on the condition that the payment instrument used can be securely authenticated, i.e. the word “contactless” should be removed in Article 8.
Article 8.2.b:
The SBA is of the opinion that recurring card payments should enjoy the same exemption as recurring credit transfers, as pointed out in comment to Rationale 17, i.e. paragraph 2 in Article 8 should be updated accordingly:
“(b) the payer initiates online a series of credit transfers or card-based payments with the same amount and the same payee.
The application of strong customer authentication shall not be exempted where the payer initiates the series of credit transfers or card-based payments for the first time or amends the series of credit transfers.”
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?
The SBA is of the opinion that the exemptions must be optional for ASPSPs.The SBA understands that the application of the exemptions is optional for the payer’s PSP (the issuer in a card context). Preventing the implementation of stronger security would be against all principles of rationality. ASPSPs take risks through liabilities and may be limited by regulations towards not taking too high risks. But regulations should never refrain ASPSPs from lowering their risks, e.g. through mandating security exemptions. Such an approach would indirectly induce also drastic reactions instead of proper risk-based reactions, should ASPSPs be confronted with new threats specifically targeting any of the exemption scenarios (e.g. massive low risk transaction fraud). Mandating exemptions could also result in unresolved situations that prevent ASPSPs to comply with other regulations (e.g. national) imposing more strict requirements.
Furthermore, the idea of allowing exemptions from the requirement on strong customer authentication, is to allow the possibility to make payment initiation more convenient for the payers. The underlying assumption is that strong customer authentication creates a hustle or at least a slower payment initiation. With the escalating innovation in customer authentication methods and technology, this is no longer the case, and will probably be so even less in the future. Many times these new strong authentication methods are more customer-friendly and convenient, than many current weak authentication methods like e.g. static passwords. For payment solutions where there is today only a strong customer authentication method offered for all transactions perceived as convenient by the users, there is no need to introduce another weak customer authentication method, that would at the same time be less customer-friendly.
Article 8.1.a.ii:
It is stated that strong customer authentication is not required for 30 days. Most online channels have a time out after a few minutes of inactivity to ensure protection of customer data. Is it really feasible to allow access without strong customer authentication for such a long period of time? Is it also feasible to allow customers through TPPs (according to the two times a day rule) access for such a long time without strong customer authentication?
The SBA finds article 8.2.a contradictive to article 2.1.b requiring signing of the amount and payee of the payment initiation. When for example a payment initiated by the PSU through a PISP is done for an e-merchant using strong customer authentication and the e-merchant is amended as a trusted beneficiary (again through strong customer authentication) should subsequent purchases (regardless of amount) at that e-merchant really be possible without using strong customer authentication? Please elaborate.
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?
The SBA agrees with EBA’s reasoning and conclusions.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 SBA welcomes the EBA´s conclusion that each ASPSP choose which communication interface it shall offer. This means that TPP must stop using the current method of direct access when the RTS is implemented.Art 17.1
The SBA considers the requirement on bilateral identification between customer and acceptance devices in need of a change or at least an explanation. The SBA’s opinion is that identification is currently done of the card to the POS terminal, no reciprocal identification of the terminal is made to the card.
Art 20.3.b
It needs to be perfectly clear that the ASPSP is aware of which parties are involved in a session or transaction. Only the name of the competent authority is not sufficient. Certain parameters in a certificate identifies the parties involved. Therefore, the SBA suggests that all parties involved in the session or transaction should be clearly displayed – both ASPSP and PIS/AIS. Customer awareness and transparency are key issues in digitalisation. Furthermore, the information should also be made available to the customer for reasons of traceability.
Article 47 (not in the RTS, related to PSD2)
Article 47 states that when a payment is initiated through a PIS the PIS shall set a payment reference and make it available to the ASPSP. The SBA assumes that this is for reasons of traceability, i.e. if a customer asks the ASPSP about the origin of a transaction according to article 46 (which contains specifics on the content of the information made available). It is important that this information is delivered in a specific format and that it follows agreed communication standards between ASPSP and PIS. Therefore, the communication in article 47 should be in scope of the RTS.
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?
No, the SBA does not see a technical constraint to use ISO 20022 as it is a global standard and likely to be developed and applied even further than today. Moreover, SEPA end date regulation 260/2012 also builds on ISO20022.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 SBA believes that it is positive to limit the number of issuers and it should be from a limited list of CA. Extended validation should also be required. E-IDAS should only be mentioned merely as an example which also was highlighted during the EBA-hearing 23 September.The RTS is unclear regarding the use of the term website certificates". The purpose of "website certificates" is to identify a server to a client and not a client to a server, even if the client is a server which described in point 70-77. The terms "client certificate" or "client authentication certificate" should be used when a client must identify itself to create clarity."
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.
Article 21.6:How will the governance model including corresponding certification process to secure that the PISP/AISP is approved according to relevant standards be constructed? What standards will apply? Will it be sufficient with ISO 27001 for PISP/AISP? Please elaborate.
Article 22.5.a:
The SBA suggests a change of the article to clarify that it is the PSU that actively is requesting such information.
..any time the payment service user actively is requesting such information,"
Article 22.5.b:
Currently, the typical customer requests data 15 times per month while third party providers request data 60 times per month. The SBA therefore suggests that automatic collection of data by AISPs without an agreed mandate with the ASPSP should not be permitted. Automatic collection has limited benefits to the PSU, it drives additional cost for the ASPSPs and decreases system performance.
If automatic data collection is introduced and executed twice per day, in spite of previous arguments, it is likely to occur at the same time each day. If this is the case it can reduce IT-system’s accessibility from which this data is requested and retrieved from. The automated data collection, should, if introduced, be as limited as possible so that the system’s performance is not negatively impacted. We cannot have an order where AIS’ service offerings result in a negative accessibility for the ASPSP´s other online services. Additionally, the AIS (and PIS) need to inform their customers clearly as to what they are consenting to and how the AIS (and PIS) intend to use the collected data.
A problem that can arise is that the consumer ends its engagement with an AIS but the AIS is still allowed to access customer data up to 30 days without the customer consenting to it (according to the 2 times a day principle). PSPs cannot control and has no knowledge whether the consumer has ended the agreement or not with the AIS.
Furthermore, a consumer protection issue is awareness. It should be made clear to the PSU which mandates the PSU has given, to whom, for which purpose and how these mandates are revoked. The ASPSPs will need to update their general conditions to regulate the responsibility between the PSU and ASPSP. Moreover, this could have potential impact on data protection regulations.
On one hand, an AIS acts only with the customer's consent and must identify themselves each time to the ASPSP and should keep the session as short as possible (see article 20-21). On the other hand the AIS should according to article 22 be able to request information not only when requested by the customer, but also two times per day. This is not consistent.
Therefore, for all of the above reasons, article 22.5.b should be deleted.
Rationale for the response:
1. Ensure customer protection
2. Session timeout similar to currently prevailing online banking standards
3. Risk for privacy and integrity issues
4. Multiple certificates likely to be required for differentiation between manual requests for account information (by PSU) and automatically initiated requests (by AISP).
Moreover, there are a lot of cases where the customer will have difficulties understanding what he/she is consenting to. Below are a couple of examples of common payment scenarios:
1. A consumer wanting a short term credit giving access to an AISP who sells the customer’s transaction history to lending providers - the transaction history subsequently sold for a 30 days period.
2. Banks want their customers to make well informed purchases based on their relevant needs and not driven by retailers’ information advantage of their customers’ online shopping behaviour.
3. If the consumer is buying a book via a PISP, the consent to initiate the purchase does not include a consent to get the account information that an AISP has the possibility to get. This type of combination of PISP/AISP should not be allowed."
Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
Swedish Bankers' AssociationPlease select which category best describes the services provided by you/your organisation
[Other"]"If you selected "Other", please provide details
The Swedish Bankers' Association represents banks in Sweden.We represent the member companies nationally and internationally:
1. We work closely with regulators and policymakers in Sweden and Europe
2. We establish joint rules in matters of common interest in the Swedish banking industry, such as payment infrastructure and security issues.
3. We inform the public about the banking sector.