Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
In general terms, we believe that regulation, such as the EBA RTS should have a principle-based character as much as possible. This to allow for robust future-proof, technology-neutral RTS, which provide for sufficient flexibility to apply appropriate market solutions, in particular regarding innovative technologies in and around the mobile phone.
Where interoperability is required, we expect the RTS to allow for an efficient implementation of the interface between the Account-Servicing Payment Service Provider (ASPSP) and the Account Information Service (AIS) provider or Payment Initiation Service (PIS) provider. The goal should be to aim for one (or at maximum a low number of) technical interface(s). Such a technical interface (preferably an API) to be developed should be open, while development should be done by a cross-industry working group. Furthermore, we would like to emphasise that the payment chain is becoming more complex. More different parties are involved. The RTS must support the creation of an environment that facilitates clear delineation of risks and liabilities.
In order to address the scale and complexity, to promote efficiency and to avoid market fragmentation, we think it is essential the RTS acknowledge the need for transparent and fully representative governance. At minima, one or several public or private bodies/authorities should be empowered with the task of developing and maintaining the technical interface standards and define and monitor the rights and responsibilities of all stakeholders. Such central governance is felt to be the only way to ensure all participants to receive the level of service they expect. In this respect, we have good experience with iDEAL as a trusted brand with a open set of rules regarding organisation of responsibilities towards both consumers and merchants.
The RTS should take into account that liabilities are largely with the ASPSP, hence the ASPSP should have sufficient means to perform its own risk analysis on individual transactions. Security of payments is increasingly based on on-the-fly analysis of various data related to the transaction, the PSU and/or the channel used; in addition to the verification of PSCs. Therefore these data have to be made available by the PIS, with the added complexity that the data elements required will evolve over time in order to improve the effectiveness of the risk analysis, while retaining or improving customer convenience. Absence of such data might result in the rejection of a payment initiation by the ASPSP.
The EBA RTS further needs to bring clarity on the security aspects with regard to the potential collection of Personalised Security Credentials (PSC) by AIS or PIS providers. The RTS would have to specify that it is mandatory to keep those safe by defining minimum requirements (e.g. in analogy to the existing security requirements in the cards framework). In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the PSU’s account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
- Imposing the liability for a transaction on the party (PIS/AIS or ASPSP) that issued the credentials.
---
Remark regarding item 27 i.: Chip cards and ATMs are included here, we assume POS-terminals are excluded.
---
The description provided in item 27 iii. (of the DP) is broad and generic. The following risks of payment fraud or other abuses should be taken into account as well:
- A specific risk can occur where the PSU uses PSCs issued by the AIS/PIS provider. In the enrolment phase the AIS/PIS provider should reliably link the PSU to one or more payment accounts belonging to a PSU and with the corresponding authorisations. If this linking has not been applied correctly, the payment account(s) can be abused. The liability for a transaction should be imposed on the party (PIS/AIS or ASPSP) that issued the credentials.
- A similar risk can occur when a PSU is registering for a new channel (for example for the mobile channel) or granting authorisation to delegated users for the access and use of payment accounts.
In general, the additional access (through the AIS/PIS provider to the ASPSP) is an additional channel at risk that can potentially be abused for fraudulent purposes.
We want to emphasise that the technology behind mobile payments evolves and that it can support two-factor authentication.
It is important that the physical element cannot be duplicated. We see the following possibilities for that:
- Authentication of the device with a challenge-response mechanism based on a key securely stored in the physical element (tablet or smartphone using a secure app, a smart card, a SIM card, a Trusted Execution Environment (TEE), etc.)
- Detection of duplication with a dynamic (session) e-cookie
We think furthermore that it is necessary and possible to allow for storing multiple sets of PSC-data (owned by one or more PSUs) within one physical device (e.g. tablet or smartphone), provided that access to a specific set of PSC-data is limited to the specific PSU that is associated with it, and that the security features of the device (access method, hardware, OS) are sufficiently reliable and secure to prevent abuse.
A basic requirement here is, that the PSU is able to verify that the possession element(s) are under his control at any moment in time, without requiring specific technological knowledge.
Any inherence element should be sufficiently secure e.g. against copying, replaying, etc.
We think that sole behaviour characteristics are currently not yet strong enough to rely on for authentication. Behaviour in combination with knowledge is not yet suitable for authentication and/or authorisation of transactions. Knowledge can be duplicated and behaviour can be learnt. On the other hand, the combination of possession and behaviour can substantially improve the level of strong customer authentication.
The use of behaviour-based characteristics should be implemented carefully and if stored, only locally and securely protected. Our advice would be to only store “derived biometric data” on the back-end for validation by the PSP. It should not be able to get the real biometrics back if the data is hacked.
A distinction should be made between the behaviour-based elements mentioned above and context-related elements (what kind of service the PSU uses, from what device, etc.). Those kind of elements we don’t consider to be behaviour-based elements while they can perfectly be used by the ASPSP as means in transaction risk analysis.
We want to stress that there is a strong market need for allowing a single device to deliver strong authentication (e.g. using a smartphone for proof of knowledge/inherence AND proof of possession), specifically from the perspective of user-friendliness. We think that current technologies are capable of sufficiently guaranteeing the independence of the two factors within the physical smartphone (e,g, Secure Element, latest version of OS, app-separation/sandboxing, remote security updates, use of different sensors, secure coding/white box cryptography, device binding).
We expect the EBA to take a risk-based approach, and draft a set of requirements for implementing Strong Customer Authentication within one physical device that is both secure enough and feasible from a user-experience perspective. The RTS should not inhibit new technologies, e.g. authentication in the cloud.
This would also give the possibility of displaying the content of the transaction in a trusted way, if desired, for verification by the PSU.
If credentials issued by the PIS/AIS provider are used, the verification should take place in the PIS/AIS provider’s environment for the same reason, but the PIS/AIS provider should deliver proof to the ASPSP that the verification has taken place.
We strongly advise against allowing the verification of PSCs issued by the ASPSP to take place within the AIS/PIS provider’s domain because of the highly increased risk of phishing and/or social engineering. It should be clear for each PSU where he can use his PSCs in a correct way/for the purpose it is meant for, and in which case it will be an attempt of phishing and/or social engineering.
• Need for ‘ease of use’. Unacceptable for PSU’s to require additional authentication device.
• Mobile platform with native apps has proven to be at least as secure when compared with the PC platform.
We refer to our answer on question 4: We think that current technologies are capable of sufficiently guaranteeing the independence of the two factors within the physical smartphone. Some examples:
• Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
• Allow only the most recent version(s) of OS
• App-separation/sandboxing
• Remote security updates, to prevent or react on possible weaknesses
• Use of different sensors (movement, camera, biometry, location/GPS)
• Secure coding/white box cryptography
• Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
• Detection of mobile malware and fraud on the device
• App-store monitoring (for malicious apps)
• Customer profiling (possibly also including location, behaviour, etc.)
We expect the EBA to draft a set of requirements for implementing Strong Customer Authentication within one physical device that is both secure enough and attractive from a user-experience perspective.
If above criteria are not sufficiently met, business cases for attacks – and hence risks – could be lowered by using (preferably user-definable) transaction limits.
Remark regarding item 38: Does this item suggest that PSPs are no longer allowed to apply geo-blocking? Some banks currently apply geo-blocking as a successful anti-fraud measure.
---
Art. 98(3) already specifies the criteria mentioned. We prefer this principle-based approach. If the liability is with the ASPSP, so the risk must be considered by the ASPSP as well. Please note that the EBA Guidelines on the Security of Internet Payments should be aligned with the RTS in due course.
Furthermore, option D actually covers all the other options, since it allows for risk-based exemptions that would presumably indicate acceptable risks for exemptions A, B, C and E. We would therefore argue to base all exemptions on D, a risk analysis that results in a sufficiently low risk, which is in line with our preference for a principle-based approach.
Therefore EBA could consider to define “risk-related thresholds” instead of an exhaustive list of exemptions related to specific kinds of transactions.
ASPSPs can distinguish between mobile banking app (the app channel) and internet banking (the internet channel). In addition to item 43, ASPSPs could implement exemptions on strong customer authentication based on the kind of channel used.
Among the criteria in item 42.D, we propose to also include the security level of the used channel(s) and the security level of the used authentication method(s).
A PIS or AIS provider is an intermediate party between the PSU and the ASPSP. The ASPSP should have sufficient means to perform its own risk analysis on individual transactions. Security of payments is increasingly based on on-the-fly analysis of various data related to the transaction, the PSU and/or the channel used; in addition to the verification of PSCs. Therefore these data have to be made available by the PIS, with the added complexity that the data elements required will evolve over time in order to improve the effectiveness of the risk analysis, while retaining or improving customer convenience. Absence of such data might result in the rejection of a payment initiation by the ASPSP. There is a potential risk that the interface between the PIS/AIS provider and the ASPSP will result in the loss of information that is required for a proper transaction risk analysis (e.g. IP address of the system/device used by the PSU). We assume that the PIS/AIS provider should be required to forward also this kind of information to the ASPSP.
All stakeholders should be encouraged to share relevant data to combat fraud. The RTS should define the conditions under which it is allowed to share (privacy-)sensitive data.
---
Yes, we believe the issue here is more about the possible fraudulent use of the PSC (via malware and/or phishing) to generate Strong Customer Authentication codes, as compared to the theft of the PSC itself. The only issue in the distribution of the PSCs is the physical theft of tokens (for example the smart card used or a security calculator). ASPSPs have procedures in place for the secure distribution of the ASPSP’s token. In our opinion principle-based legislation is most suited to ensure that these procedures are sufficiently secure.
In item 52, a clarification regarding the prevention of phishing should be added (as mentioned in 51.D).
As already touched upon in our answer to question 5, phishing can be prevented if the use of PSCs is limited to secure environments that are recognizable by the PSU as being trusted environments (to limit/prevent phishing risks). One of the most effective anti-phishing measures is education of the PSU about where to enter his PSCs and how to recognize these as trusted environments. If the PSU is accustomed to entering his PSCs in many different environments (at many different AIS/PIS providers) it becomes difficult to recognize a phishing-attempt at a rogue AIS/PIS provider, and it will be impossible to educate the PSU about how to recognize the trusted environments.
In our opinion, the best solution is therefore to limit the use of PSCs to the (secure and recognizable) domain of the issuer of the PSC. The PSU will thus be confronted with only one environment, that he can recognize and trust, and the PSC-issuer can effectively educate the PSU to not enter the PSC in other domains. Use of the PSC will thus be limited to e.g. the secure app of the PSC-issuer on the PSU-device (smartphone) or online via a secure link in the server-environment of the PSC-issuer.
• Derived identification, or remote identification. Example: send an image of an ID-document via the app, transfer money from own account to bind the account, enter unique codes that are sent via SMS or being pushed, register device (device binding) and register one’s face (or other biometric aspects). This is during the preparatory step before actual enrolment of the PSCs.
• Using out-of-bound push notification to activate the mobile device for authentication. Example: after PSU clicks on the login button on the internet banking site, a message is pushed to the device that has been bound to the client (using device binding techniques). The PSU then logs in in the app on the device, and at that time he will also automatically be logged in in the internet banking site. The same method can be used when the PSU wants to log in via a regular telephone, where the notification message on the bound device and the following login in the app on the bound device, serve as an extra verification for access to the telephone service center.
• Device binding (secure activation of an app for use by only one PSU on only one device).
• NFC with the debit card against NFC phones, to validate a transaction, authentication and authorization.
• Use of smart watches as an extra validation etc.
In general, certification is better than evaluation. Certification implies a fixed set of rules to comply with and the possibility to revoke the certification. Evaluation is as good as the person/organization performing it and the results are recommendations without enforcements.
N.B. The complexity of the problem (and by that the cost of certification) is reduced in case the PSCs are only created and transmitted within the secure environment of the PSC-issuer.
Risks are most likely to occur at the PSU, specifically the phishing risks and other methods used to mislead the PSU in using his PSCs in environments that are accessible or controlled by fraudsters. PSU education is one of the key measures to be taken in this matter. In the Netherlands in recent years, internet banking fraud figures have decreased significantly. We strongly believe that PSU education has contributed to this positive development.
In general, the more parties or entities that play a significant role in the payment chain (e.g. processing sensitive payment data), the more places there are where risks are introduced.
Remark regarding item 61: In order to address the scale and complexity, to promote efficiency and to avoid market fragmentation, we think it is essential the RTS acknowledge the need for transparent and fully representative governance. At minima, one or several public or private bodies/authorities should be empowered with the task of developing and maintaining the technical interface standards and define and monitor the rights and responsibilities of all stakeholders. Such central governance is felt to be the only way to ensure all participants to receive the level of service they expect. In this respect, we have good experience with iDEAL as a trusted brand with a open set of rules regarding organisation of responsibilities towards both consumers and merchants.
Remark regarding item 62: Referring to the last sentence (solution implementations by ASPSPs should not be too divergent to prevent becoming a barrier for AIS and PIS providers): we would like to stress that the reverse is also true – ASPSPs should not be confronted with too much divergence in implementations by AIS and PIS providers. The ASPSPs implementations should be economically feasible, future proof and maintainable.
Remark regarding item 63: We question why EBA seems to leave Third Party Payment Instrument Issuers (PSD2 – Art. 65) out of scope of this paragraph.
---
Yes, basically this suffices. NB: We believe an AIS/PIS provider should not only forward transaction-related information to the ASPSP, but also information about the process itself (time of payment process, IP address, etc.), possibly depending on the risk profile of the transaction. This kind of information can be used by ASPSP in its fraud monitoring process. It should be possible for the ASPSP to specify which information it wants. See also our answer on question 9.
63 d. The consent of the PSU should be conveyed to the ASPSP. This can be realized by “redirection” of a customer. It is essential that the ASPSP can verify that the customer has given consent for activities regarding a specific account.
In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the actual account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
The redirection model, combined with tokenisation, is to be preferred. The PSU is redirected to its ASPSP to login and create credentials (tokens) for linking the PIS or AIS provider to the ASPSP. In other words: the redirection model (either on a pc or via mobile app) is used for the verification of credentials provided by the ASPSP; the mechanism of tokenisation is used to initiate a payment based on authentication of the payer by a PIS or AIS provider.
Access via AIS/PIS providers will have less functionality, compared to direct access by the PSU to the ASPSP. Taking into account the assumption that an ASPSP will not be required to provide different credentials for access via AIS/PIS providers, the RTS should include a mechanism to determine the level and scope of authorisations provided by the PSU via the PIS/AIS provider to the ASPSP.
- Screen scraping should be explicitly excluded as a way to implement an interface.
- Interface should be RESTful (in particular stateless)
- The interface specification(s) should support version control. The number of versions to be supported should be limited. Guidance should be given on this number and the migration timespan.
- The ASPSP is supplying the service: AIS/PIS providers should adapt to the service delivered by the ASPSPs and not the other way around.
- ASPSPs should be able to continue to use existing means for authentication, to keep existing levels of security and have the freedom to change authentication means when it requires so.
- Strong authentication should be used for the authentication of the AIS/PIS provider to the ASPSP.
- The ASPSP is allowed to limit the access of a PSU through a AIS/PIS provider to the functions required by the PSD2 directive. These functions should be specified.
- As a consequence, AIS/PIS providers should be able to rely on the authentication of the PSU by the ASPSP but it should not be necessary for the PSU to give his full PSCs to the AIS/PIS provider. One way to do this is redirection of the customer (to the ASPSP).
ASPSPs must have access to contextual information on payer and payee for fraud detection purposes. It should be possible for the ASPSP to specify which information it needs.
Other standards that are currently in development in the payments area are, for example: SAML, OAuth (both existing) and W3C Web Payments (in development). The RTS should take care that definitions, etc. are as much as possible consistent with definitions in SAML, OAuth *) and W3C (when available).
*) A number of Dutch banks use the market standard OAuth2.0, where we think the following options offer the required functions:
• OAUTH 2.0 - Client credentials flow for use of where the AIS/PIS provider does the PSC verifications
• OAUTH 2.0 – Resource Owner flow for use where the ASPSP does the verification of the PSC
Only the ASPSP knows who is authorised to use an account and under what circumstances. In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the actual account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
- Imposing the liability for a transaction on the party (PIS/AIS or ASPSP) that issued the credentials.
eIDAS is set up from a government perspective which has some issues with alignment with banking industry (a person and the role of the person is not distinct).
eIDAS and PSD2 have separate implementation timelines. Linking these timelines will create unwanted dependencies.
It is very well possible that the costs of implementing and using qualified trust services will be considered as too high in the light of our impression that RTS will not require such a high level of security.
1. With respect to Article 97(1) (c), are there any additional examples of transactions or actions implying a risk of payment fraud or other abuses that would need to be considered for the RTS? If so, please give details and explain the risks involved.
Before answering the questions, we would like to emphasise some aspects in our reaction:In general terms, we believe that regulation, such as the EBA RTS should have a principle-based character as much as possible. This to allow for robust future-proof, technology-neutral RTS, which provide for sufficient flexibility to apply appropriate market solutions, in particular regarding innovative technologies in and around the mobile phone.
Where interoperability is required, we expect the RTS to allow for an efficient implementation of the interface between the Account-Servicing Payment Service Provider (ASPSP) and the Account Information Service (AIS) provider or Payment Initiation Service (PIS) provider. The goal should be to aim for one (or at maximum a low number of) technical interface(s). Such a technical interface (preferably an API) to be developed should be open, while development should be done by a cross-industry working group. Furthermore, we would like to emphasise that the payment chain is becoming more complex. More different parties are involved. The RTS must support the creation of an environment that facilitates clear delineation of risks and liabilities.
In order to address the scale and complexity, to promote efficiency and to avoid market fragmentation, we think it is essential the RTS acknowledge the need for transparent and fully representative governance. At minima, one or several public or private bodies/authorities should be empowered with the task of developing and maintaining the technical interface standards and define and monitor the rights and responsibilities of all stakeholders. Such central governance is felt to be the only way to ensure all participants to receive the level of service they expect. In this respect, we have good experience with iDEAL as a trusted brand with a open set of rules regarding organisation of responsibilities towards both consumers and merchants.
The RTS should take into account that liabilities are largely with the ASPSP, hence the ASPSP should have sufficient means to perform its own risk analysis on individual transactions. Security of payments is increasingly based on on-the-fly analysis of various data related to the transaction, the PSU and/or the channel used; in addition to the verification of PSCs. Therefore these data have to be made available by the PIS, with the added complexity that the data elements required will evolve over time in order to improve the effectiveness of the risk analysis, while retaining or improving customer convenience. Absence of such data might result in the rejection of a payment initiation by the ASPSP.
The EBA RTS further needs to bring clarity on the security aspects with regard to the potential collection of Personalised Security Credentials (PSC) by AIS or PIS providers. The RTS would have to specify that it is mandatory to keep those safe by defining minimum requirements (e.g. in analogy to the existing security requirements in the cards framework). In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the PSU’s account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
- Imposing the liability for a transaction on the party (PIS/AIS or ASPSP) that issued the credentials.
---
Remark regarding item 27 i.: Chip cards and ATMs are included here, we assume POS-terminals are excluded.
---
The description provided in item 27 iii. (of the DP) is broad and generic. The following risks of payment fraud or other abuses should be taken into account as well:
- A specific risk can occur where the PSU uses PSCs issued by the AIS/PIS provider. In the enrolment phase the AIS/PIS provider should reliably link the PSU to one or more payment accounts belonging to a PSU and with the corresponding authorisations. If this linking has not been applied correctly, the payment account(s) can be abused. The liability for a transaction should be imposed on the party (PIS/AIS or ASPSP) that issued the credentials.
- A similar risk can occur when a PSU is registering for a new channel (for example for the mobile channel) or granting authorisation to delegated users for the access and use of payment accounts.
In general, the additional access (through the AIS/PIS provider to the ASPSP) is an additional channel at risk that can potentially be abused for fraudulent purposes.
2. Which examples of possession elements do you consider as appropriate to be used in the context of strong customer authentication, must these have a physical form or can they be data? If so, can you provide details on how it can be ensured that these data can only be controlled by the PSU?
Possession elements cannot be copied, whereas data can be copied. Therefore, we believe at least a relevant part of the possession elements should have a physical form. We consider the tablet and or smartphone, when used with an app, to be a physical element. This is under the assumption that the initial binding of the device with the user and its payment account is realized with different authentication elements, e.g. the possession elements used for internet banking (i.e. a chip card offering EMV CAP capabilities or similar; or a security calculator).We want to emphasise that the technology behind mobile payments evolves and that it can support two-factor authentication.
It is important that the physical element cannot be duplicated. We see the following possibilities for that:
- Authentication of the device with a challenge-response mechanism based on a key securely stored in the physical element (tablet or smartphone using a secure app, a smart card, a SIM card, a Trusted Execution Environment (TEE), etc.)
- Detection of duplication with a dynamic (session) e-cookie
We think furthermore that it is necessary and possible to allow for storing multiple sets of PSC-data (owned by one or more PSUs) within one physical device (e.g. tablet or smartphone), provided that access to a specific set of PSC-data is limited to the specific PSU that is associated with it, and that the security features of the device (access method, hardware, OS) are sufficiently reliable and secure to prevent abuse.
A basic requirement here is, that the PSU is able to verify that the possession element(s) are under his control at any moment in time, without requiring specific technological knowledge.
3. Do you consider that in the context of “inherence” elements, behaviour-based characteristics are appropriate to be used in the context of strong customer authentication? If so, can you specify under which conditions?
Yes, if the behaviour-based elements are sufficiently distinctive from the other authentication elements (i.e. providing low levels of false positives and false negatives). However, privacy legislation should be respected when using behaviour-based elements.Any inherence element should be sufficiently secure e.g. against copying, replaying, etc.
We think that sole behaviour characteristics are currently not yet strong enough to rely on for authentication. Behaviour in combination with knowledge is not yet suitable for authentication and/or authorisation of transactions. Knowledge can be duplicated and behaviour can be learnt. On the other hand, the combination of possession and behaviour can substantially improve the level of strong customer authentication.
The use of behaviour-based characteristics should be implemented carefully and if stored, only locally and securely protected. Our advice would be to only store “derived biometric data” on the back-end for validation by the PSP. It should not be able to get the real biometrics back if the data is hacked.
A distinction should be made between the behaviour-based elements mentioned above and context-related elements (what kind of service the PSU uses, from what device, etc.). Those kind of elements we don’t consider to be behaviour-based elements while they can perfectly be used by the ASPSP as means in transaction risk analysis.
4. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to the independence of the authentication elements used (e.g. for mobile devices)?
A good common practise for authentication on a mobile device is the use of a userid and password (knowledge) and proof of the use of the mobile device and/or the SIM card by an SMS TAN code or the result of using a security token (possession). This suffices when a customer uses the “normal” internet banking solution on the mobile (www.bankx.country or m.bankx.country). When a mobile app is used, the initial binding should be sufficiently secure. The possession of the mobile with the app is sufficient for proofing possession. Knowledge is in that case the pin/ password, which should never be stored in the mobile device.We want to stress that there is a strong market need for allowing a single device to deliver strong authentication (e.g. using a smartphone for proof of knowledge/inherence AND proof of possession), specifically from the perspective of user-friendliness. We think that current technologies are capable of sufficiently guaranteeing the independence of the two factors within the physical smartphone (e,g, Secure Element, latest version of OS, app-separation/sandboxing, remote security updates, use of different sensors, secure coding/white box cryptography, device binding).
We expect the EBA to take a risk-based approach, and draft a set of requirements for implementing Strong Customer Authentication within one physical device that is both secure enough and feasible from a user-experience perspective. The RTS should not inhibit new technologies, e.g. authentication in the cloud.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
Dynamic linking of the authentication with transaction details should take place in a secure environment (to avoid man-in-the-middle risk in components between the PSU and the ASPSP). This should also be recognizable by the PSU as being a trusted environment to reduce phishing risks. The best solution (in terms of security and feasibility) is to generate the dynamically linked authentication codes within the recognizable and trusted environment of the issuer of the PSC, for instance in a secure app of the PSC-issuer on the PSU’s device (smartphone or tablet) or online via a secure link in the server-environment of the PSC-issuer.This would also give the possibility of displaying the content of the transaction in a trusted way, if desired, for verification by the PSU.
If credentials issued by the PIS/AIS provider are used, the verification should take place in the PIS/AIS provider’s environment for the same reason, but the PIS/AIS provider should deliver proof to the ASPSP that the verification has taken place.
We strongly advise against allowing the verification of PSCs issued by the ASPSP to take place within the AIS/PIS provider’s domain because of the highly increased risk of phishing and/or social engineering. It should be clear for each PSU where he can use his PSCs in a correct way/for the purpose it is meant for, and in which case it will be an attempt of phishing and/or social engineering.
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
Two important external factors in this regard, are:• Need for ‘ease of use’. Unacceptable for PSU’s to require additional authentication device.
• Mobile platform with native apps has proven to be at least as secure when compared with the PC platform.
We refer to our answer on question 4: We think that current technologies are capable of sufficiently guaranteeing the independence of the two factors within the physical smartphone. Some examples:
• Secure Element (SIM or dedicated chip) for storage of sensitive data, accessible only by PSU and authorized app
• Allow only the most recent version(s) of OS
• App-separation/sandboxing
• Remote security updates, to prevent or react on possible weaknesses
• Use of different sensors (movement, camera, biometry, location/GPS)
• Secure coding/white box cryptography
• Device binding (secure activation of an app for use by only one PSU on only one device), based on continually refreshed data elements or challenge/response
• Detection of mobile malware and fraud on the device
• App-store monitoring (for malicious apps)
• Customer profiling (possibly also including location, behaviour, etc.)
We expect the EBA to draft a set of requirements for implementing Strong Customer Authentication within one physical device that is both secure enough and attractive from a user-experience perspective.
If above criteria are not sufficiently met, business cases for attacks – and hence risks – could be lowered by using (preferably user-definable) transaction limits.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
Remark regarding item 37: For some banks it is actually not true that paper forms are not protected. They use paper forms that contain a counter and a cryptographic check code.Remark regarding item 38: Does this item suggest that PSPs are no longer allowed to apply geo-blocking? Some banks currently apply geo-blocking as a successful anti-fraud measure.
---
Art. 98(3) already specifies the criteria mentioned. We prefer this principle-based approach. If the liability is with the ASPSP, so the risk must be considered by the ASPSP as well. Please note that the EBA Guidelines on the Security of Internet Payments should be aligned with the RTS in due course.
Furthermore, option D actually covers all the other options, since it allows for risk-based exemptions that would presumably indicate acceptable risks for exemptions A, B, C and E. We would therefore argue to base all exemptions on D, a risk analysis that results in a sufficiently low risk, which is in line with our preference for a principle-based approach.
Therefore EBA could consider to define “risk-related thresholds” instead of an exhaustive list of exemptions related to specific kinds of transactions.
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
A risk-based approach is essential when deciding about exemptions. If the liability is with the ASPSP, so the risk must be considered by the ASPSP as well.ASPSPs can distinguish between mobile banking app (the app channel) and internet banking (the internet channel). In addition to item 43, ASPSPs could implement exemptions on strong customer authentication based on the kind of channel used.
Among the criteria in item 42.D, we propose to also include the security level of the used channel(s) and the security level of the used authentication method(s).
9. Are there any other criteria or circumstances which the EBA should consider with respect to transaction risks analysis as a complement or alternative to the criteria identified in paragraph 45?
No, the criteria for this transaction risk-analysis should be principle-based. It is up to a PSP to decide on the exact capabilities of the fraud detection based on its own risk analysis and appetite. The competent authority will be the party judging whether the implemented fraud detection suffices in this matter.A PIS or AIS provider is an intermediate party between the PSU and the ASPSP. The ASPSP should have sufficient means to perform its own risk analysis on individual transactions. Security of payments is increasingly based on on-the-fly analysis of various data related to the transaction, the PSU and/or the channel used; in addition to the verification of PSCs. Therefore these data have to be made available by the PIS, with the added complexity that the data elements required will evolve over time in order to improve the effectiveness of the risk analysis, while retaining or improving customer convenience. Absence of such data might result in the rejection of a payment initiation by the ASPSP. There is a potential risk that the interface between the PIS/AIS provider and the ASPSP will result in the loss of information that is required for a proper transaction risk analysis (e.g. IP address of the system/device used by the PSU). We assume that the PIS/AIS provider should be required to forward also this kind of information to the ASPSP.
All stakeholders should be encouraged to share relevant data to combat fraud. The RTS should define the conditions under which it is allowed to share (privacy-)sensitive data.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
Remark regarding item 52 ii., in particular the phrase “all communication channels (…) need to be resistant to tampering and unauthorized access“. We note that this is almost impossible to achieve. Standard (secure) protocols such as SSL1/2/3 and TLS1.0/1,2 were considered to be secure until new vulnerabilities were found. Such a requirement in the RTS would be too strongly formulated. Requirements for the resilience against tampering and unauthorised access should be formulated on messages and application protocols instead of the communication channels.---
Yes, we believe the issue here is more about the possible fraudulent use of the PSC (via malware and/or phishing) to generate Strong Customer Authentication codes, as compared to the theft of the PSC itself. The only issue in the distribution of the PSCs is the physical theft of tokens (for example the smart card used or a security calculator). ASPSPs have procedures in place for the secure distribution of the ASPSP’s token. In our opinion principle-based legislation is most suited to ensure that these procedures are sufficiently secure.
In item 52, a clarification regarding the prevention of phishing should be added (as mentioned in 51.D).
As already touched upon in our answer to question 5, phishing can be prevented if the use of PSCs is limited to secure environments that are recognizable by the PSU as being trusted environments (to limit/prevent phishing risks). One of the most effective anti-phishing measures is education of the PSU about where to enter his PSCs and how to recognize these as trusted environments. If the PSU is accustomed to entering his PSCs in many different environments (at many different AIS/PIS providers) it becomes difficult to recognize a phishing-attempt at a rogue AIS/PIS provider, and it will be impossible to educate the PSU about how to recognize the trusted environments.
In our opinion, the best solution is therefore to limit the use of PSCs to the (secure and recognizable) domain of the issuer of the PSC. The PSU will thus be confronted with only one environment, that he can recognize and trust, and the PSC-issuer can effectively educate the PSU to not enter the PSC in other domains. Use of the PSC will thus be limited to e.g. the secure app of the PSC-issuer on the PSU-device (smartphone) or online via a secure link in the server-environment of the PSC-issuer.
11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
See our answer to question 10 and our comments regarding 52 ii.12. Have you identified innovative solutions for the enrolment process that the EBA should consider which guarantee the confidentiality, integrity and secure transmission (e.g. physical or electronic delivery) of the users’ personalised security credentials?
We have identified a number of relevant innovative enrolment processes, depending sometimes on the channel used:• Derived identification, or remote identification. Example: send an image of an ID-document via the app, transfer money from own account to bind the account, enter unique codes that are sent via SMS or being pushed, register device (device binding) and register one’s face (or other biometric aspects). This is during the preparatory step before actual enrolment of the PSCs.
• Using out-of-bound push notification to activate the mobile device for authentication. Example: after PSU clicks on the login button on the internet banking site, a message is pushed to the device that has been bound to the client (using device binding techniques). The PSU then logs in in the app on the device, and at that time he will also automatically be logged in in the internet banking site. The same method can be used when the PSU wants to log in via a regular telephone, where the notification message on the bound device and the following login in the app on the bound device, serve as an extra verification for access to the telephone service center.
• Device binding (secure activation of an app for use by only one PSU on only one device).
• NFC with the debit card against NFC phones, to validate a transaction, authentication and authorization.
• Use of smart watches as an extra validation etc.
13. Can you identify alternatives to certification or evaluation by third parties of technical components or devices hosting payment solutions, to ensure that communication channels and technical components hosting, providing access to or transmitting the personalised security credential are sufficiently resistant to tampering and unauthorized access?
We assume that existing and approved (self-)certification rules and processes are taken into account for setting concrete requirements in the RTS.In general, certification is better than evaluation. Certification implies a fixed set of rules to comply with and the possibility to revoke the certification. Evaluation is as good as the person/organization performing it and the results are recommendations without enforcements.
N.B. The complexity of the problem (and by that the cost of certification) is reduced in case the PSCs are only created and transmitted within the secure environment of the PSC-issuer.
14. Can you indicate the segment of the payment chain in which risks to the confidentiality, integrity of users’ personalised security credentials are most likely to occur at present and in the foreseeable future?
The PSU is still the weakest link in this matter, including the usage of his devices (malware on the PC/jailbreaking the smartphone device, etc.). We believe the segment in the payment chain with the highest risk to the confidentiality and integrity of the users’ PSCs, is the time between sending off credentials (by the PSU) and the moment the ASPSP receives them.Risks are most likely to occur at the PSU, specifically the phishing risks and other methods used to mislead the PSU in using his PSCs in environments that are accessible or controlled by fraudsters. PSU education is one of the key measures to be taken in this matter. In the Netherlands in recent years, internet banking fraud figures have decreased significantly. We strongly believe that PSU education has contributed to this positive development.
In general, the more parties or entities that play a significant role in the payment chain (e.g. processing sensitive payment data), the more places there are where risks are introduced.
15. For each of the topics identified under paragraph 63 above (a to f), do you consider the clarifications provided to be comprehensive and suitable? If not, why not?
Remark regarding item 57 ii. This item states: “Regulated PSPs, including AIS/PIS providers will have to comply with all the security measures deriving from the PSD2 (title IV) and delegated acts (title V). As explained in the background section, it is important to underline that only 18 months after their adoption by the Commission, PSPs will have to comply with the Regulatory Technical Standards on strong customer authentication and secure communication.” This means that an AIS/PIS provider can start and work for 2 years without security? During this time it is possible that the AIS/PIS provider does not comply with all requirements mentioned in item 57 vi. It is unacceptable for ASPSPs to be held liable for any damages resulting from non-compliance in this regard.Remark regarding item 61: In order to address the scale and complexity, to promote efficiency and to avoid market fragmentation, we think it is essential the RTS acknowledge the need for transparent and fully representative governance. At minima, one or several public or private bodies/authorities should be empowered with the task of developing and maintaining the technical interface standards and define and monitor the rights and responsibilities of all stakeholders. Such central governance is felt to be the only way to ensure all participants to receive the level of service they expect. In this respect, we have good experience with iDEAL as a trusted brand with a open set of rules regarding organisation of responsibilities towards both consumers and merchants.
Remark regarding item 62: Referring to the last sentence (solution implementations by ASPSPs should not be too divergent to prevent becoming a barrier for AIS and PIS providers): we would like to stress that the reverse is also true – ASPSPs should not be confronted with too much divergence in implementations by AIS and PIS providers. The ASPSPs implementations should be economically feasible, future proof and maintainable.
Remark regarding item 63: We question why EBA seems to leave Third Party Payment Instrument Issuers (PSD2 – Art. 65) out of scope of this paragraph.
---
Yes, basically this suffices. NB: We believe an AIS/PIS provider should not only forward transaction-related information to the ASPSP, but also information about the process itself (time of payment process, IP address, etc.), possibly depending on the risk profile of the transaction. This kind of information can be used by ASPSP in its fraud monitoring process. It should be possible for the ASPSP to specify which information it wants. See also our answer on question 9.
63 d. The consent of the PSU should be conveyed to the ASPSP. This can be realized by “redirection” of a customer. It is essential that the ASPSP can verify that the customer has given consent for activities regarding a specific account.
In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the actual account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
The redirection model, combined with tokenisation, is to be preferred. The PSU is redirected to its ASPSP to login and create credentials (tokens) for linking the PIS or AIS provider to the ASPSP. In other words: the redirection model (either on a pc or via mobile app) is used for the verification of credentials provided by the ASPSP; the mechanism of tokenisation is used to initiate a payment based on authentication of the payer by a PIS or AIS provider.
Access via AIS/PIS providers will have less functionality, compared to direct access by the PSU to the ASPSP. Taking into account the assumption that an ASPSP will not be required to provide different credentials for access via AIS/PIS providers, the RTS should include a mechanism to determine the level and scope of authorisations provided by the PSU via the PIS/AIS provider to the ASPSP.
16. For each agreed clarification suggested above on which you agree, what should they contain in your view in order to achieve an appropriate balance between harmonisation, innovation while preventing too divergent practical implementations by ASPSPs of the future requirements?
The RTS should specify complete interfaces including the technical level for those interfaces for which interoperability is required, in particular between PIS/AIS providers and ASPSPs. The goal should be to aim for one (or at maximum a low number of) technical interface(s). Such a technical interface (preferably an API) to be developed should be open, while development should be done by a cross-industry working group.- Screen scraping should be explicitly excluded as a way to implement an interface.
- Interface should be RESTful (in particular stateless)
- The interface specification(s) should support version control. The number of versions to be supported should be limited. Guidance should be given on this number and the migration timespan.
- The ASPSP is supplying the service: AIS/PIS providers should adapt to the service delivered by the ASPSPs and not the other way around.
- ASPSPs should be able to continue to use existing means for authentication, to keep existing levels of security and have the freedom to change authentication means when it requires so.
- Strong authentication should be used for the authentication of the AIS/PIS provider to the ASPSP.
- The ASPSP is allowed to limit the access of a PSU through a AIS/PIS provider to the functions required by the PSD2 directive. These functions should be specified.
- As a consequence, AIS/PIS providers should be able to rely on the authentication of the PSU by the ASPSP but it should not be necessary for the PSU to give his full PSCs to the AIS/PIS provider. One way to do this is redirection of the customer (to the ASPSP).
ASPSPs must have access to contextual information on payer and payee for fraud detection purposes. It should be possible for the ASPSP to specify which information it needs.
17. In your opinion, is there any standards (existing or in development) outlining aspects that could be common and open, which would be especially suitable for the purpose of ensuring secure communications as well as for the appropriate identification of PSPs taking into consideration the privacy dimension?
We are aware that such standards exist, that partly fulfil the requirements, such as iDEAL.Other standards that are currently in development in the payments area are, for example: SAML, OAuth (both existing) and W3C Web Payments (in development). The RTS should take care that definitions, etc. are as much as possible consistent with definitions in SAML, OAuth *) and W3C (when available).
*) A number of Dutch banks use the market standard OAuth2.0, where we think the following options offer the required functions:
• OAUTH 2.0 - Client credentials flow for use of where the AIS/PIS provider does the PSC verifications
• OAUTH 2.0 – Resource Owner flow for use where the ASPSP does the verification of the PSC
18. How would these requirement for common and open standards need to be designed and maintained to ensure that these are able to securely integrate other innovative business models than the one explicitly mentioned under article 66 and 67 (e.g. issuing of own credentials by the AIS/PIS)?
The requirements for common and open standards should be as much as possible principle-based and should support interoperable implementations. The development and maintenance of the actual standards can be left to the market.Only the ASPSP knows who is authorised to use an account and under what circumstances. In case the PIS or AIS provider issues its own credentials, we would like to emphasize that the RTS should take care of :
- Ensuring the safe coupling of these external credentials with the actual account at the ASPSP, including specific permissions to delegated users that are associated with the account. And the ability for the account holder to disable this coupling, for instance in case of loss of the credentials.
- Imposing the liability for a transaction on the party (PIS/AIS or ASPSP) that issued the credentials.
19. Do you agree that the e-IDAS regulation could be considered as a possible solution for facilitating the strong customer authentication, protecting the confidentiality and the integrity of the payment service users’ personalised security credentials as well as for common and secure open standards of communication for the purpose of identification, DP on future RTS on strong customer and secure communication under PSD2 31 authentication, notification, and information? If yes, please explain how. If no, please explain why.
The eIDAS regulation has not been drafted for application in the payment domain. We feel that applying the eIDAS regulation would be too much of an artificial solution. Nevertheless, we expect consistent legislation (eIDAS vs PSD2). The mechanism of eIDAS can potentially be applied in the onboarding of PSUs.eIDAS is set up from a government perspective which has some issues with alignment with banking industry (a person and the role of the person is not distinct).
eIDAS and PSD2 have separate implementation timelines. Linking these timelines will create unwanted dependencies.
20. Do you think in particular that the use of “qualified trust services” under e-IDAS regulation could address the risks related to the confidentiality, integrity and availability of PSCs between AIS, PIS providers and ASPSPs? If yes, please identify which services and explain how. If no, please explain why.
See 19. Our impression is that the requirement for “qualified trust services” is too strong for the RTS. However, market parties can decide to use qualified trust services.It is very well possible that the costs of implementing and using qualified trust services will be considered as too high in the light of our impression that RTS will not require such a high level of security.