Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
The Austrian banking community agrees on the general approach and reasoning, though some topics need further explanation and clarification. We have found a few issues which we recommend looking into:
a) Recital 22
It is hard to understand what is referring to what. Are there other Authentication Elements that are not personalized security credentials (PSC)?
b) Recital 26
There are other techniques available to create an adequately secured and protected environment to display the amount and the account number of the payee in order to ensure the integrity of data towards the payment service user (PSU) on a smartphone with an Internet banking app. It should be required that the payee and amount are visible on the system that is used to sign the transaction.
c) Recital 29
Use of the behavioral data should be excluded as a standalone inherence element. Behavioral data and behavioral biometrics are not the same. Behavioral data could be used as an inherence element.
d) Art 1 in general
Is it correct to derive from this article that magnetic stripe cards will no longer be allowed for payment systems?
e) Art 1 (1)
A more specific formulation is required to clarify. Present text seems impractical for the sequence of REST API calls needed to complete one transaction. Also it does not allow existence of refresh token" for the continuous access to the account from the account information service provider (AISP).
There is the need to provide a more elaborate distinction between authentication code (access code) and authorization code to initiate a transaction.
f) Art. 1 (3) lit a
Definitely, a kind of time-out regulation in online-banking-systems shall be provided. Though, this only makes sense if a time-out is executed in case of inactivity of the user. A general time-out is not appropriate. Customer should not be subject to time out when he is active in the Internet Banking application. Such time out should only apply to "non activity time" only.
g) Art 1 (3) lit e
It is not clear what is „PSP's final authorization“? Is this the payment service provider’s (PSP) confirmation to PSU that transaction is accepted or the moment when transaction is actually processed and money is transferred? Does this presume that fraud detection systems should be implemented as real-time in-line systems?
h) Art 1 (3) lit b
Even if we agree with the principle in general, there are situations especially for card payments where a feedback to the payer about what went wrong has proven as helpful. E.g. showing the message “wrong PIN” on a POS-terminal when the entered PIN was wrong has proven as helpful.
i) Art 1 (3) lit e
This article seems to go beyond the mandate given by PSD 2. Therefore the text shall be modified as follows “… prevent, detect and block transactions based on compromised PSCs or authentication codes to the extent possible. These mechanisms shall may take into account, but not be limited to: (i) ….”
j) Art 2 (1) lit a
Difficult to apply for file processing: How to show client total amount and each several payee if the batch contains 100ths of transactions e.g. big corporates?
k) Art 2 (2) lit b
Please clarify what needs to be segregated from what. It is not clear if using one device, yet segregation done by channel is correct (i.e. existence of two mobile apps - one as a banking app, the second to receive the payment confirmation).
l) Art 2 (3)
As defined in the explanations (at the beginning of the document) transactions issued at the POS are excluded from the dynamic linking. This article would re-include them. To be cleared with EBA what is the rule.
m) Art 3 (1)
The general understanding is that the factor "knowledge" is the password in combination with the user ID but it has to be confirmed if the user ID is part of the knowledge elements or if the password (or PIN) is the only one parameter to be categorized as knowledge.
We are aware that the elements categorised as knowledge have to comply with minimum standards of complexity. On the other hand they need to be convenient enough for customers to memorize so that there is no need to write them down. We therefore recommend that the text of the article is changed from “shall” to “should” or the terms “length” and “complexity” should be erased to be able to adapt the complexity if needed. With the wording “should” the necessary flexibility for future developments can be kept.
Also the term “use of non-repeatable characters” is not clear in this context. Does it mean that characters should not be used more than once in a row or within the entire string of e. g. a password? We ask for clarification.
n) Art 4 (1):
We ask for clarification: Is the possession of a mobile phone (i.e. possession of phone number) considered as possession?
Is the SMS itself considered as a possession?
o) Art 5:
We ask for clarification: What does “template protection features” mean?
Is it mandatory to have: biometric sensor and template protection features for all platforms (cards, online banking)?
In this regard please clarify as well Art 5 (2).
p) Art 6
The article can not be applied as it would oblige banks to enter into the software and/or hardware of devices of their customers to install security features and control mechanisms at this level.
q) Art 6 (2) and Art 6 (3) lit b
Of course all ASPSPs will take appropriate measures to protect their own banking- and/or security-applications against fraud and tampering. However, no involved party (ASPSPs, PSPs, customers,…) is able to prevent manipulation of operating systems on mobile phones or tablets. Neither, a change of physical parts can be prevented by ASPSPs. Multi-purpose devices of consumers should be considered outside of scope of control of ASPSPs. Therefore we suggest adapting this article in a way that the PSP shall mitigate the consequences for consumers when the consumer uses the services of the PSP on a compromised multi-purpose device.
r) Art 6 (3)
We think it will be better to give some examples to mitigate the risks regarding the usage of multi-purpose devices. Therefore we suggest to alter the text as follows “For the purposes of paragraph 2, the mitigating measures shall may include, but are not limited to …”
s) Art 6 (3) lit a
We recommend to use the term „segregated secure environment“ instead of „separated trusted execution environment“. The term “Trusted Execution Environment” (acronym TEE) is directly linked to a technical concept described in a Global Platform standard. Therefore it would be better to replace this term by “a segregated secure environment”.
We ask for clarification separated trusted execution environments inside multi-purpose devices and ask thereby taking into account that there are several platforms for developing applications not only those that offer native sandboxing."
In general we welcome the flexibility offered on where and when the dynamic linking takes place. Regarding EMV based card transactions it shall be clarified that either
• the cryptographic data generated during an EMV transaction is considered as valid, dynamically linked authentication code, even if this code is not typed in again from the payer or
• there is no additional authentication code needed for EMV based card transactions.
The requirement according to Art 2 (2) lit b, that the channel through which the information (amout and payee) is displayed, shall be independent or segregated from the channel used for initiating the electronic payment transaction is seen critical. It is obvious that many customers will set their multi-purpose-smartphone as the channel/device, through which the dynamic password is received. This could implicate that through this device no online purchases could be made. An initiation of payments through this device would have to be prevented or a separate device would have to be provided, which the customer would have to have always on himself. This would contradict all convenience efforts.
The rationale of the draft RTS on the one hand and the PSD 2 on the other hand allow for optional exemptions as well as they grant a risk-based assessment by ASPSPs which is already in use today. The wording should be adapted to allow exemptions, but based on the decision of the bank. The concept of “risk based exception” should also be included in the RTS to allow ASPSP to offer exceptions based on their own risk analysis profile of each customer. We highly recommend to respect PSD 2 Article 98 (3) lit a where exemptions may be based on the level of risk involved in the service provided. A list provided by EBA of possible criteria for such an approach is not necessary to our opinion.
For this particular point EBA’s strategy to exempt only a few dedicated cases from SCA seems to contradict the level 1-text. EBA’s approach leaves out the risk based approach described in the PSD 2. We would support the specification of parameters that can at least be used for risk based transaction analyses and to take a decision whether strong authentication must be performed or not.
It is not clear which payment data are sensitive, there is a need for an accurate definition. For example: Is access to the transaction history considered as sensitive payment data?
Under the condition, that no sensible data is disclosed and no transactions are initiated, the access to the account online would not require SCA. This is welcome as the mere examination of payment information would not require SCA and therefore increase convenience.
Art 8 (1)
If strong customer authentication is exempted, what applies instead? Does it mean that in exempted cases a 1-factor authentication is enough or does it mean that no authentication is required?
Art 8 (1) lit a
This point allows the access to Internet banking without SCA under condition that Internet banking is not offering active operations to clients. Is it valid? How does it coexist with recommendations for the security of Internet payments "?
Art 8 (1) lit a ii
One month is too short, if AISPs are to provide the functionality of personal finance management systems, it is unbearable often to provide strong authentication for each aggregated financial product each month. Some users will login only a couple of times per month, or even once a month, to check on their finances. If they will have to go through strong authentication procedure every month, they will quickly abandon the service, because the effort to keep their profile up to date will be too much. It will create users apathy and will not result in users using such services. A reasonable time for such period would be 1 year.
ASPSP should have the possibility to use a risk based approach instead of a fixed period of time.
Art 8 (1) lit b
This article mentions „contactless electronic payment transaction at a point of sale“. We recommend to remove the word „contactless“ since the exemptions for electronic card payments at the POS should be the same for contact and contactless transactions. For normal card transactions where the card is inserted at the POS same rules should apply.
Further, the amount limits of € 50 and € 150 may meet today's demands, nevertheless we recommend to define these limits in an annex to the RTS to make future changes easier.
It does not state for which period the cumulative amount is computed. Our suggestion is to put it as a daily limit.
Recurring card based payments are not addressed yet and shall therefore be added to the text.
Art 8 (2) general
The conclusion of the interpretation of this article is that only the SCA is exempted (not the dynamic linking). So to be consistent with the PSD 2, this article would have to refer to PSD 2 Art 97 (1) and (2) and not only to Art 97 (2). A mere exemption from Art 97 (2) PSD 2 would contradict convenience regarding low risk payments. Therefore the complete SCA (inclusive the dynamic linking) should be exempted.
Art 8 (2) lit a
We request towards EBA to extend the exemption to "closed communities" in order to maintain the functioning of online payments systems (like eps in Austria). ASPSPs should be allowed to offer white lists of trustworthy payees, for which no initial white-listing by the user is required.
Art 8 (2) lit b
The term “standing order” should be used in the RTS.
A series of credit transfers is not an immediate payment initiation – erase or describe use case.
Art 8 (2) lit d
The amount limit of € 10 for „remote electronic payment transactions“ is too low. Moreover, it is not clear why there is a difference between a contactless payment at the POS and a remote payment with respect to maximum amount. The limits for remote payments should therefore match the limits for payment transactions at the POS (Art. 8 (1) lit b) as customers should not be bothered with different amount limits. And again as mentioned above the limits should be defined in an annex to the RTS to make future changes easier.
It does not state for which period the cumulative amount is computed. Our suggestion is to put it as a daily limit."
Art 9 (1) lit a
This paragraph should be rephrased as it now indicates that a transaction-code transmitted by ASPSPs to a user’s mobile-phone shall not be readable on this device. We assume that only codes/passwords which are typed into an online-banking-interface shall not be readable during typing. Also here a risk based approach should be supported. Because there are good arguments for permitting a user to get a short view of what was keyed into an authentication field. Please also clarify that data on personalised security credentials shall not be readable for PISPs/AISPs. In general data on personalized security credentials should be defined.
Art 9 (1) lit c
The text “secure and tamper resistant devices and environments” should be replaced by “security hardened devices and environments (SW)”, as it is impossible for ASPSPs to ensure that devices or software-environments are not altered or hacked.
Art 9 (2)
The article mentions that „the process… shall be fully documented within the authentication procedure.“ This should be rephrased in „… it shall be fully documented within the authentication documentation“. Please rephrase or otherwise clarify. The description of the process related to the management of cryptographic material used must be included in a separate documentation; it cannot be part of the authentication itself.
Art 11
It is unclear what is exactly meant by the requirement that the risks of unauthorized use of the personalized security credentials and of the authentication devices and software due to their loss, theft or copying before their delivery to the payer are effectively addressed"?
Art 12(b)
The paragraph missed to define the first implementation of a device, because at this point of time, a SCA is not possible.
Art 13 (d)
Clarification is needed for “trusted environment” (art. 12, 13).
Art 14
There is a difference between a scheduled renewal of expired credentials and the replacement of stolen credentials. Therefore, it seems too rigorous to have the same procedures for renewal and re-activation.
Art 15 (c)
We ask for specification of "information related to PSC".
What is meant with "public repositories" -> certificates CRL?"
Common understanding is that each ASPSP can define its own communication interface, and only offer this one and that it must not support/accept any other ones.
To be clarified by EBA: When an ASPSP offers one interface based on API, it may reject any attempt made by a TPP through https? Clarification will be needed, when an ASPSP is offering an access via API, that it is allowed to “block” any other access means (like https) to AISP/PISP.
Art 17
Clarification is needed how new certificates attribute will looks like. Each certificate per role (PIPs/AIS/) or one certificate with multiple roles?
Art 17 (1)
For EMV based card transactions at POS terminals the request for “secure bilateral identification between the payer’s device and payee’s accepting device” creates an incompatibility with the existing EMV standard where terminal authentication is not required.
Art 17 (2)
We suggest adopting the term “protected” to “adequately protected” (see also comment on article 6.2).
We disagree with the requirement that payment services providers shall ensure that mobile applications and other payment services users’ interfaces offering electronic payment services are protected against misdirection of communication to unauthorized third parties". Mobile devices are under the control of clients, if they install malware into their devices, the payment service providers may not be responsible.
Art 19 (1)
The RTS should define, that the communication interface should not be based only on batch-processing uploads and downloads (i.e. FTP and similar), but also on real-time communication technology.
Art 19 (2) lit a
Please clarify the purpose of the “authentication procedure” in this context. From our point of view the authentication process is never a stand-alone procedure but is always a part of a process. (e. g. login to online-banking; initiate a credit transfer,…).
Art 19 (6)
Testing environments shall be excluded from the statements same level of SLA.
Art 20 (3)
The RTS should list the exact names of attributes, define constraints on their values, list the codebook for license types and give the link to a official list of names of competent authorities (as these can be spelled in various ways, a consolidated list is required to be used as values in certificates).
Art. 21 (5)
The obligation for AISPs and PISPS immediately to contact the issuer of personalised security credentials in case of loss of confidentiality of these credentials can only be fulfilled, when appropriate contact data are available. Furthermore we miss the responsibility provision for financial loss in such cases for the AISP/PISP.
The requirement that PSC are not accessible to any of the staff is not achievable. Especially in the case when AISP is entitled to repeated requests for information from ASPSP without the user interaction - in that case the AISP needs to be able to authenticate client on client’s behalf, i.e. AISP needs to provide client’s PSC.
Art 21(6)
Please clarify if the bank shall use the common security standards (ISO 27001) as guideline or shall be compliant with the ISO 27001 standard and certified accordingly.
Art 22
General aspects to be cleared in this context are:
Which kind of data must be made available as a minimum requested by the AISP? The understanding is normal payment information, but no interest/account fees information.
How long has the transaction history to be provided to AIS?
Which kind of operations ASPSPs should enable over the account to PISPs?
Art 22 (1) lit a
Does this include: Overdraft limit, waiting transactions (i.e. those with future execution dates), failed transactions, standing orders and their details, direct debit authorizations, list of disponents, list of associated payment instruments and their details (including daily/monthly spending limits, transaction categories, names of payee account holders, etc.).
Art 22 (1) lit b
Does this include information on payment orders (especially standing orders) initiated through other PISPs? The reasoning is that PISP should be able to handle transactions over the account - i.e. PISP should be able to cancel or modify a standing order (for example a pension fund would like to use PISP-based services offered at pension fund website to enable its clients to increase their monthly contributions by altering existing standing orders).
Does this include the display of a list of accounts held by usera at a given ASPSP? (the reason is the user should be able to choose the account without the need for the user to enter the account manually). Also, for the benefit of both the user and PISP, PISP should be able to display account balances of the listed accounts, so the user can choose the account with sufficient balance, and so the PISP can limit its credit risk by checking the availability of funds before initiating the transaction and before informing the payee that the transaction has been initiated so the payee can release the purchased goods. If the PISP does not have the option to check the availability of funds, he is in same risk as if the card-issuing TPP cannot check the availability of funds on the associated account.
Art 22 (2)
Proper information regarding the status of a process in any stage of the procedure to all involved parties is vital. However, in some circumstances not all parties may be informed properly (e.g. server unable to respond). Therefore we recommend to add “if possible” to this paragraph or to rephrase it.
Art 22 (5) lit b
RTS should state, that AISP must provide information in the request if the request is or is not actively requested by service user. If such information is not provided, ASPSP cannot introduce any throttling limits on the interface."
The actual wording of the RTS is not detailed enough.
Comments based on ETSI/EN standards are still to come on eIDAS and qualified certificates.
What in case that no eIDAS qualified trust service providers will exist by October 2018? Can some kind of manual registration with ASPSP and only one-way TLS be used (no mutual authentication on API)? Processes for eIDAS certification, certification revocation, etc are missing.
Art 20
Will there be another RTS regarding eIDAS registration, control and procedures issued?
Please find above our complemented remarks. The uploaded comments from Oct. 5th should be considered redundant.
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?
Please find in the following our complemented remarks. The uploaded comments from Oct. 5th should be considered redundant.The Austrian banking community agrees on the general approach and reasoning, though some topics need further explanation and clarification. We have found a few issues which we recommend looking into:
a) Recital 22
It is hard to understand what is referring to what. Are there other Authentication Elements that are not personalized security credentials (PSC)?
b) Recital 26
There are other techniques available to create an adequately secured and protected environment to display the amount and the account number of the payee in order to ensure the integrity of data towards the payment service user (PSU) on a smartphone with an Internet banking app. It should be required that the payee and amount are visible on the system that is used to sign the transaction.
c) Recital 29
Use of the behavioral data should be excluded as a standalone inherence element. Behavioral data and behavioral biometrics are not the same. Behavioral data could be used as an inherence element.
d) Art 1 in general
Is it correct to derive from this article that magnetic stripe cards will no longer be allowed for payment systems?
e) Art 1 (1)
A more specific formulation is required to clarify. Present text seems impractical for the sequence of REST API calls needed to complete one transaction. Also it does not allow existence of refresh token" for the continuous access to the account from the account information service provider (AISP).
There is the need to provide a more elaborate distinction between authentication code (access code) and authorization code to initiate a transaction.
f) Art. 1 (3) lit a
Definitely, a kind of time-out regulation in online-banking-systems shall be provided. Though, this only makes sense if a time-out is executed in case of inactivity of the user. A general time-out is not appropriate. Customer should not be subject to time out when he is active in the Internet Banking application. Such time out should only apply to "non activity time" only.
g) Art 1 (3) lit e
It is not clear what is „PSP's final authorization“? Is this the payment service provider’s (PSP) confirmation to PSU that transaction is accepted or the moment when transaction is actually processed and money is transferred? Does this presume that fraud detection systems should be implemented as real-time in-line systems?
h) Art 1 (3) lit b
Even if we agree with the principle in general, there are situations especially for card payments where a feedback to the payer about what went wrong has proven as helpful. E.g. showing the message “wrong PIN” on a POS-terminal when the entered PIN was wrong has proven as helpful.
i) Art 1 (3) lit e
This article seems to go beyond the mandate given by PSD 2. Therefore the text shall be modified as follows “… prevent, detect and block transactions based on compromised PSCs or authentication codes to the extent possible. These mechanisms shall may take into account, but not be limited to: (i) ….”
j) Art 2 (1) lit a
Difficult to apply for file processing: How to show client total amount and each several payee if the batch contains 100ths of transactions e.g. big corporates?
k) Art 2 (2) lit b
Please clarify what needs to be segregated from what. It is not clear if using one device, yet segregation done by channel is correct (i.e. existence of two mobile apps - one as a banking app, the second to receive the payment confirmation).
l) Art 2 (3)
As defined in the explanations (at the beginning of the document) transactions issued at the POS are excluded from the dynamic linking. This article would re-include them. To be cleared with EBA what is the rule.
m) Art 3 (1)
The general understanding is that the factor "knowledge" is the password in combination with the user ID but it has to be confirmed if the user ID is part of the knowledge elements or if the password (or PIN) is the only one parameter to be categorized as knowledge.
We are aware that the elements categorised as knowledge have to comply with minimum standards of complexity. On the other hand they need to be convenient enough for customers to memorize so that there is no need to write them down. We therefore recommend that the text of the article is changed from “shall” to “should” or the terms “length” and “complexity” should be erased to be able to adapt the complexity if needed. With the wording “should” the necessary flexibility for future developments can be kept.
Also the term “use of non-repeatable characters” is not clear in this context. Does it mean that characters should not be used more than once in a row or within the entire string of e. g. a password? We ask for clarification.
n) Art 4 (1):
We ask for clarification: Is the possession of a mobile phone (i.e. possession of phone number) considered as possession?
Is the SMS itself considered as a possession?
o) Art 5:
We ask for clarification: What does “template protection features” mean?
Is it mandatory to have: biometric sensor and template protection features for all platforms (cards, online banking)?
In this regard please clarify as well Art 5 (2).
p) Art 6
The article can not be applied as it would oblige banks to enter into the software and/or hardware of devices of their customers to install security features and control mechanisms at this level.
q) Art 6 (2) and Art 6 (3) lit b
Of course all ASPSPs will take appropriate measures to protect their own banking- and/or security-applications against fraud and tampering. However, no involved party (ASPSPs, PSPs, customers,…) is able to prevent manipulation of operating systems on mobile phones or tablets. Neither, a change of physical parts can be prevented by ASPSPs. Multi-purpose devices of consumers should be considered outside of scope of control of ASPSPs. Therefore we suggest adapting this article in a way that the PSP shall mitigate the consequences for consumers when the consumer uses the services of the PSP on a compromised multi-purpose device.
r) Art 6 (3)
We think it will be better to give some examples to mitigate the risks regarding the usage of multi-purpose devices. Therefore we suggest to alter the text as follows “For the purposes of paragraph 2, the mitigating measures shall may include, but are not limited to …”
s) Art 6 (3) lit a
We recommend to use the term „segregated secure environment“ instead of „separated trusted execution environment“. The term “Trusted Execution Environment” (acronym TEE) is directly linked to a technical concept described in a Global Platform standard. Therefore it would be better to replace this term by “a segregated secure environment”.
We ask for clarification separated trusted execution environments inside multi-purpose devices and ask thereby taking into account that there are several platforms for developing applications not only those that offer native sandboxing."
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 Austrian banking community agrees and welcomes the reasoning. We agree, the requirements for the “dynamic linking” procedure should remain technically neutral and should not impact the way the PSPs are implementing the processes.In general we welcome the flexibility offered on where and when the dynamic linking takes place. Regarding EMV based card transactions it shall be clarified that either
• the cryptographic data generated during an EMV transaction is considered as valid, dynamically linked authentication code, even if this code is not typed in again from the payer or
• there is no additional authentication code needed for EMV based card transactions.
The requirement according to Art 2 (2) lit b, that the channel through which the information (amout and payee) is displayed, shall be independent or segregated from the channel used for initiating the electronic payment transaction is seen critical. It is obvious that many customers will set their multi-purpose-smartphone as the channel/device, through which the dynamic password is received. This could implicate that through this device no online purchases could be made. An initiation of payments through this device would have to be prevented or a separate device would have to be provided, which the customer would have to have always on himself. This would contradict all convenience efforts.
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?
We do not see any further threats, the elements mentioned in articles 3, 4 and 5 are sufficient. It is unclear what is meant by the term “non-repeatable characters”. Therefore it is suggested to remove this term.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 RTS themselves and question 5 indicate that the exemptions to SCA are mandatory. It should be ensured that making exemptions from SCA is optional and not mandatory for PSPs. As PSPs have the liability they should have the freedom to apply SCA in risky cases.The rationale of the draft RTS on the one hand and the PSD 2 on the other hand allow for optional exemptions as well as they grant a risk-based assessment by ASPSPs which is already in use today. The wording should be adapted to allow exemptions, but based on the decision of the bank. The concept of “risk based exception” should also be included in the RTS to allow ASPSP to offer exceptions based on their own risk analysis profile of each customer. We highly recommend to respect PSD 2 Article 98 (3) lit a where exemptions may be based on the level of risk involved in the service provided. A list provided by EBA of possible criteria for such an approach is not necessary to our opinion.
For this particular point EBA’s strategy to exempt only a few dedicated cases from SCA seems to contradict the level 1-text. EBA’s approach leaves out the risk based approach described in the PSD 2. We would support the specification of parameters that can at least be used for risk based transaction analyses and to take a decision whether strong authentication must be performed or not.
It is not clear which payment data are sensitive, there is a need for an accurate definition. For example: Is access to the transaction history considered as sensitive payment data?
Under the condition, that no sensible data is disclosed and no transactions are initiated, the access to the account online would not require SCA. This is welcome as the mere examination of payment information would not require SCA and therefore increase convenience.
Art 8 (1)
If strong customer authentication is exempted, what applies instead? Does it mean that in exempted cases a 1-factor authentication is enough or does it mean that no authentication is required?
Art 8 (1) lit a
This point allows the access to Internet banking without SCA under condition that Internet banking is not offering active operations to clients. Is it valid? How does it coexist with recommendations for the security of Internet payments "?
Art 8 (1) lit a ii
One month is too short, if AISPs are to provide the functionality of personal finance management systems, it is unbearable often to provide strong authentication for each aggregated financial product each month. Some users will login only a couple of times per month, or even once a month, to check on their finances. If they will have to go through strong authentication procedure every month, they will quickly abandon the service, because the effort to keep their profile up to date will be too much. It will create users apathy and will not result in users using such services. A reasonable time for such period would be 1 year.
ASPSP should have the possibility to use a risk based approach instead of a fixed period of time.
Art 8 (1) lit b
This article mentions „contactless electronic payment transaction at a point of sale“. We recommend to remove the word „contactless“ since the exemptions for electronic card payments at the POS should be the same for contact and contactless transactions. For normal card transactions where the card is inserted at the POS same rules should apply.
Further, the amount limits of € 50 and € 150 may meet today's demands, nevertheless we recommend to define these limits in an annex to the RTS to make future changes easier.
It does not state for which period the cumulative amount is computed. Our suggestion is to put it as a daily limit.
Recurring card based payments are not addressed yet and shall therefore be added to the text.
Art 8 (2) general
The conclusion of the interpretation of this article is that only the SCA is exempted (not the dynamic linking). So to be consistent with the PSD 2, this article would have to refer to PSD 2 Art 97 (1) and (2) and not only to Art 97 (2). A mere exemption from Art 97 (2) PSD 2 would contradict convenience regarding low risk payments. Therefore the complete SCA (inclusive the dynamic linking) should be exempted.
Art 8 (2) lit a
We request towards EBA to extend the exemption to "closed communities" in order to maintain the functioning of online payments systems (like eps in Austria). ASPSPs should be allowed to offer white lists of trustworthy payees, for which no initial white-listing by the user is required.
Art 8 (2) lit b
The term “standing order” should be used in the RTS.
A series of credit transfers is not an immediate payment initiation – erase or describe use case.
Art 8 (2) lit d
The amount limit of € 10 for „remote electronic payment transactions“ is too low. Moreover, it is not clear why there is a difference between a contactless payment at the POS and a remote payment with respect to maximum amount. The limits for remote payments should therefore match the limits for payment transactions at the POS (Art. 8 (1) lit b) as customers should not be bothered with different amount limits. And again as mentioned above the limits should be defined in an annex to the RTS to make future changes easier.
It does not state for which period the cumulative amount is computed. Our suggestion is to put it as a daily limit."
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?
See the first paragraph of question 4. Again the Austrian banking community strongly supports a risk-based analysis as stated in the PSD 2. Furthermore, the application of exemptions shall be optional for ASPSPs as regulation should not keep ASPSPs from managing their risks (as well as their liability). Furthermore an adaptive authentication/authorization" approach could also be included to allow more flexibility for ASPSP to their customers."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 Austrian banking community agrees though we found a few issues which we recommend to clarify:Art 9 (1) lit a
This paragraph should be rephrased as it now indicates that a transaction-code transmitted by ASPSPs to a user’s mobile-phone shall not be readable on this device. We assume that only codes/passwords which are typed into an online-banking-interface shall not be readable during typing. Also here a risk based approach should be supported. Because there are good arguments for permitting a user to get a short view of what was keyed into an authentication field. Please also clarify that data on personalised security credentials shall not be readable for PISPs/AISPs. In general data on personalized security credentials should be defined.
Art 9 (1) lit c
The text “secure and tamper resistant devices and environments” should be replaced by “security hardened devices and environments (SW)”, as it is impossible for ASPSPs to ensure that devices or software-environments are not altered or hacked.
Art 9 (2)
The article mentions that „the process… shall be fully documented within the authentication procedure.“ This should be rephrased in „… it shall be fully documented within the authentication documentation“. Please rephrase or otherwise clarify. The description of the process related to the management of cryptographic material used must be included in a separate documentation; it cannot be part of the authentication itself.
Art 11
It is unclear what is exactly meant by the requirement that the risks of unauthorized use of the personalized security credentials and of the authentication devices and software due to their loss, theft or copying before their delivery to the payer are effectively addressed"?
Art 12(b)
The paragraph missed to define the first implementation of a device, because at this point of time, a SCA is not possible.
Art 13 (d)
Clarification is needed for “trusted environment” (art. 12, 13).
Art 14
There is a difference between a scheduled renewal of expired credentials and the replacement of stolen credentials. Therefore, it seems too rigorous to have the same procedures for renewal and re-activation.
Art 15 (c)
We ask for specification of "information related to PSC".
What is meant with "public repositories" -> certificates CRL?"
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?
Indeed the Austrian banking community supports the use of common and secure open standards. When designing the interface, each entity will use the required key elements mentioned in the RTS to ensure easy accessibility to all participating parties. The description is very high level and will need more detailed specification for the implementation phase, but in general we agree on the reasoning and especially that ASPSP shall offer at least one communication interface and that there is no obligation to offer more than one.Common understanding is that each ASPSP can define its own communication interface, and only offer this one and that it must not support/accept any other ones.
To be clarified by EBA: When an ASPSP offers one interface based on API, it may reject any attempt made by a TPP through https? Clarification will be needed, when an ASPSP is offering an access via API, that it is allowed to “block” any other access means (like https) to AISP/PISP.
Art 17
Clarification is needed how new certificates attribute will looks like. Each certificate per role (PIPs/AIS/) or one certificate with multiple roles?
Art 17 (1)
For EMV based card transactions at POS terminals the request for “secure bilateral identification between the payer’s device and payee’s accepting device” creates an incompatibility with the existing EMV standard where terminal authentication is not required.
Art 17 (2)
We suggest adopting the term “protected” to “adequately protected” (see also comment on article 6.2).
We disagree with the requirement that payment services providers shall ensure that mobile applications and other payment services users’ interfaces offering electronic payment services are protected against misdirection of communication to unauthorized third parties". Mobile devices are under the control of clients, if they install malware into their devices, the payment service providers may not be responsible.
Art 19 (1)
The RTS should define, that the communication interface should not be based only on batch-processing uploads and downloads (i.e. FTP and similar), but also on real-time communication technology.
Art 19 (2) lit a
Please clarify the purpose of the “authentication procedure” in this context. From our point of view the authentication process is never a stand-alone procedure but is always a part of a process. (e. g. login to online-banking; initiate a credit transfer,…).
Art 19 (6)
Testing environments shall be excluded from the statements same level of SLA.
Art 20 (3)
The RTS should list the exact names of attributes, define constraints on their values, list the codebook for license types and give the link to a official list of names of competent authorities (as these can be spelled in various ways, a consolidated list is required to be used as values in certificates).
Art. 21 (5)
The obligation for AISPs and PISPS immediately to contact the issuer of personalised security credentials in case of loss of confidentiality of these credentials can only be fulfilled, when appropriate contact data are available. Furthermore we miss the responsibility provision for financial loss in such cases for the AISP/PISP.
The requirement that PSC are not accessible to any of the staff is not achievable. Especially in the case when AISP is entitled to repeated requests for information from ASPSP without the user interaction - in that case the AISP needs to be able to authenticate client on client’s behalf, i.e. AISP needs to provide client’s PSC.
Art 21(6)
Please clarify if the bank shall use the common security standards (ISO 27001) as guideline or shall be compliant with the ISO 27001 standard and certified accordingly.
Art 22
General aspects to be cleared in this context are:
Which kind of data must be made available as a minimum requested by the AISP? The understanding is normal payment information, but no interest/account fees information.
How long has the transaction history to be provided to AIS?
Which kind of operations ASPSPs should enable over the account to PISPs?
Art 22 (1) lit a
Does this include: Overdraft limit, waiting transactions (i.e. those with future execution dates), failed transactions, standing orders and their details, direct debit authorizations, list of disponents, list of associated payment instruments and their details (including daily/monthly spending limits, transaction categories, names of payee account holders, etc.).
Art 22 (1) lit b
Does this include information on payment orders (especially standing orders) initiated through other PISPs? The reasoning is that PISP should be able to handle transactions over the account - i.e. PISP should be able to cancel or modify a standing order (for example a pension fund would like to use PISP-based services offered at pension fund website to enable its clients to increase their monthly contributions by altering existing standing orders).
Does this include the display of a list of accounts held by usera at a given ASPSP? (the reason is the user should be able to choose the account without the need for the user to enter the account manually). Also, for the benefit of both the user and PISP, PISP should be able to display account balances of the listed accounts, so the user can choose the account with sufficient balance, and so the PISP can limit its credit risk by checking the availability of funds before initiating the transaction and before informing the payee that the transaction has been initiated so the payee can release the purchased goods. If the PISP does not have the option to check the availability of funds, he is in same risk as if the card-issuing TPP cannot check the availability of funds on the associated account.
Art 22 (2)
Proper information regarding the status of a process in any stage of the procedure to all involved parties is vital. However, in some circumstances not all parties may be informed properly (e.g. server unable to respond). Therefore we recommend to add “if possible” to this paragraph or to rephrase it.
Art 22 (5) lit b
RTS should state, that AISP must provide information in the request if the request is or is not actively requested by service user. If such information is not provided, ASPSP cannot introduce any throttling limits on the interface."
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?
We agree that ISO 20022 elements should be used, especially for payments initiation as defined in the regulation (EU) No 260/2012 (The SEPA Regulation). We do not see any technical constraints that would prevent the use of the elements mentioned above. It must be clear that the ISO20022 is the format of the file that will be exchanged between ASPSP and PISP/AISP. The technical communication interface must have another modern communication standard, for example: JSON/REST (nowadays widely used in API, mobile applications and JS frameworks).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 Austria banking community emphasises that qualified certificates assure the quality of identification and agrees to use qualified website certificates according to eIDAS and the ETSI standards 319 412-1 to -5 v.1.1.1. However, EBA has to take care, that these standards are amended to satisfy the needs of the ASPSPs, i.e. identifying PSPs by its type, registration number and registration authority within the website certificate. For instance ETSI 319 412-1 v.1.1.1 and the definitions of id-etsi-qcs-SemanticsId-Legal need to be amended with the acronyms “PIS” and “AIS” so that the term “PISAT-012378999” is a valid entry identifying an Austrian PISP. A reference to eIDAS Annex II or equivalent regulations is missing.The actual wording of the RTS is not detailed enough.
Comments based on ETSI/EN standards are still to come on eIDAS and qualified certificates.
What in case that no eIDAS qualified trust service providers will exist by October 2018? Can some kind of manual registration with ASPSP and only one-way TLS be used (no mutual authentication on API)? Processes for eIDAS certification, certification revocation, etc are missing.
Art 20
Will there be another RTS regarding eIDAS registration, control and procedures issued?
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 Austrian banking community agrees to the frequency as specified in Art 22 (5) lit b. However there will be a need to distinguish between automatic" access and "human" access when PISP/AIS will use dedicated API.The ASPSP must be in a position to determine whether a certain request is according to 22 (5) lit a or lit b, e.g. by providing customer credentials when customer based."Please select which category best describes you and/or your organisation
[Other "]"If you selected "Other", please provide details
legal representative of the entire Austrian banking and insurance industryPlease find above our complemented remarks. The uploaded comments from Oct. 5th should be considered redundant.