Response to discussion on RTS on strong customer authentication and secure communication under PSD2
Go back
Incidentally, we would like to stress that direct debit should be out of scope of strong customer authentication for transaction initiating: direct debit transactions are not initiated by the payer but by the payee. Accordingly, the direct debit risk model is inherently different from ‘push payments’ (i.e. payments initiated by the payer), for which the payer’s authentication is relevant.
- Mobile App
o Factor 1: PIN, Biometrics
o Factor 2: Possession evidence by cryptographic key, device fingerprinting
o Non-transferable cryptographic keys, unique device fingerprints, organizational constraints: preventing hand over device and PIN to a third party, PSU education and awareness, notification channel between PSU/PP.
- Mobile Phone
o Factor 1: PIN
o Factor 2: possession evidence by personal phone number
o organizational constraints: preventing hand over device and PIN to third party, PSU education and awareness, notification channel between PSU/PP.
- Biometric components in smartphones
o Rely on vendor mechanisms: e.g. Apple Touch ID
o Factor 1: Biometrics
o Factor 2: possession evidenced by cryptographic device key.
- Tokenization
o Factor 1: PIN
o Factor 2: Possession evidence by device bound token-based payment instrument.
We consider that it is not necessary that the PSU has the sole control of the possession elements, as these can be also held by the entity mandated by the PSU (e.g. by an AIS / PIS on behalf of the payer). The current definition of authentication in the PSD2 seems to support the principle that security credentials can be used by the PSP. (1 Art. 4. 29 of the PSD2: authentication" means a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials.)"
Therefore, we consider behaviour-based characteristics can be used very effectively in the context of SCA under the condition that the authentication system for the “inherence” elements is sufficiently accurate (e.g. providing a low crossover error rate and provided the transaction patterns are maintained constantly up to date).
However, using hardware to secure/separate communication channels poses the following major issues, depending on the PSU’s environment:
PSU cannot install/connect personal hardware on workplace equipment,
The handling of specific devices rely on PSU level of education/awareness,
Multi-step authentication needs PSU expertise,
Authentication methods have to be simple to prevent social engineering,
Low user adoption rate due to the inconvenience of having to carry additional devices.
Kindly note that we are unconvinced that the challenge is merely isolating the channels/ ensuring that the authentication elements are as independent as possible. In our view, effective solutions in this area must also meet the criteria of usability and convenience from the PSU’s perspective. A logical (software-based) separation of payment and authentication channel can be sufficiently secure (e.g. a mobile browser for shopping and paying, and an authentication app on the same device can be considered strong authentication) provided the software/ apps are isolated in a way that their security architectures don’t interfere.
Software-based authentication can also deploy new defence strategies in case of incidents/ vulnerabilities of the authentication process. Should a major incident require adjustments, logistics, development and certification processes of hardware-based authentication elements could preclude the availability of payment instruments for weeks.
Given the current trend toward mobile centric interaction in the digital finance, we would strongly advise against regulatory requirements mandating a separation of hardware token for authentication.
Linking transaction amount and payee implies accuracy of both data. Though the PSU might be aware of the transaction amount (yet, in some cases the amount might be unknown in advance) validating the name/IBAN of the payee is not always possible.2 Therefore, except in cases where the PSU enters the transaction data directly, the PSU will have to rely on the PSP for this data.
The PSD2 does not seem to clarify how the payee’s data will be protected and validated, especially for transactions initiated by TPPs.3 Also, it is unclear who is responsible for the dynamic linking (PIS,ASPSP or PSU?). We consider that both the ASPSP and the PSU could support the dynamic linking on a technical level. These are some of the possible implementations:
- On the ASPSP side a secured table assigns transaction data to the PSU’s authentication token ( e.g. a SMS token)
- On the PSU side an app assigns the transaction data to the PSU’s identity, (e.g. by a cryptographic hash or a digital signature).
However, SCA with dynamic linking is feasible only for transactions in which the PSU interacts directly with the PSP. Therefore, there are several different scenarios in which dynamic linking will not be possible. We would recommend the RTS to allow exemptions to the SCA with dynamic linking: not only there are more reliable and user friendly alternatives to it (e.g. PayPal deploys sophisticated technologies supporting validation of PSU’s identity and detection of early attempts of fraud, with very limited friction for users) but this requirement might be excessively burdensome in some cases (e.g. low risk transactions).
With this said, below we list some of the solutions that, depending on the type of transaction, can be effective in ensuring independence and dynamic linking in the mobile environment:
- Mobile SMS token, if the mobile is used as second channel and shopping via PC/mobile browser + notification/validation via payments app/email,
- Mobile authentication app which is able to receive secured transaction data and interacts with PSU for confirmation,
- Mobile payments app, if the app is separated from shopping/paying channel (e.g. payment app is different from browser/in-app shopping) and app signs/hashs the transaction data with PSU specific key,
- Physical hardware token which is able to receive the transaction data/token from ASPSP, PISP or PSU-environment.
We particularly appreciate clarifications on risk-based authentication, which is critical to stimulate wider users’ adoption and to ensure digital payment solutions are safe and user friendly for unproblematic transactions. Also, security methods based on a risk assessment can reduce attack vectors, thanks to the flexibility of the response and the context-specific features of the security tool. Finally, risk-based security enables improved incident management, due to a faster response to fraud risks and flexible adjustment of the authentication process.
With this said, we would recommend the RTS to mention the potential exemptions as a reference list only, which should not prevent other exemptions to be granted (based on a case-by-case assessment) by home state financial supervisors. This dynamic approach is needed not only to adequately stimulate EU innovation in the security field, but also to accommodate the constant changing patterns of online fraud and consumer behaviour (both driven by the adoption of new technologies).
- Risk structure of the underlying payment instrument,
- Risk structure of the Payment System / PSP,
- Context of the payment transaction and control measures,
- Use cases and transaction risk (e.g. low value, limits, organizational measures or legislation, limited fraud case, etc.).
For (a) and (b), in consideration of potential attacks to financial sources (attacks on the PSU side), an additional criterion could be the patterns of fraudulent financial insolvency. Such criteria can support early detection and consolidation of fraudulent financial flows. Another useful criterion could be the distributed patterns of transactions (attack wave patterns).
However, we respectfully recommend that the elements (a), (b) and (c) mentioned in paragraph 45 are not set as mandatory factors, i.e. PSPs should not be mandated to use only these elements when performing their risk assessment. As discussed in our response to question 7 above, a dynamic approach is needed to take into account innovation and developments in the fast changing digital ecosystem.
- Weak algorithms for generating user credentials,
- Physical access to hardware from personal environment,
- Social engineering,
- Hardware weakness and availability of hardware, connections, no fall back processes.
However risks are constantly arising as fraudsters continuously develop new targets and strategies while new customers’ patterns and technologies arise.
- FIDO standard,
- App/token based on cryptographically secured self-enrolment with activation codes.
- Regular penetration testing based on standardized methodologies
- Certification only for critical infrastructures with high volume or high market impact
- Vendors of authentication software: certify the development process, rather than the software.
- PSU,
- PSU Interface,
- Authentication method,
- Fall back processes,
- Enrolment process.
-
We have identified unlikely or unusual segments as follows:
- Transmission channel
- PSP online service
- PSP back-end
- PSP employees
b) TLS/SSL are technologies considered best practice to secure the communication without the need for a contract-based symmetric key exchange. The mutual validation of the party’s certificate implies trusted Certification Authorities and real-time certificate validation (e.g. via OCSP). This implies the secure provision of EBA’s register entries (the entities common name and certificate) to the communication partners.
Example: TLS/SSL are technologies considered best practice to secure the communication for ad-hoc communication. Symmetric key exchange could also be possible for contract-based communication
c) PIS:
- Establish mutual authenticated secure connection,
- Submit the transaction data,
- Link between transaction data and PSU is done by PIS, ASPSP or PSU, depending on the solution,
- Trigger/process the PSU authentication
- Get success/error message about payment order processing.
AIS:
- Establish mutual authenticated secure connection,- Trigger/progress the PSU authentication or provide permission for recurrent account information request,
- Receive all payment transaction data or update only,
- Receive account data and information about available data.
Availability of funds:
- Establish mutual authenticated secure connection,
- Submit the account id, amount and transaction reference,
- Receive confirmation message (yes/no) about availability of funds.
d) e) For a reliable service the API of ASPSP should be able to set limits for the number of times an account can be accessed, how many times a PIS/AIS/PSP can access an ASPSP. The mutual authentication should rely on real-time validation of keys e.g. OSCP. The EBA register should be secured and rely on hardened services.
f) PIS: The initiation of a SEPA credit transfer re-using as much as possible from the SEPA CT rulebook. Return messages based on ISO 20022. AIS: Messages based on ISO 20022, CAMT, no difference in scope and extent from the default online user interface. Availability of funds: Messages based on ISO 20022.
- For secure communication: TLS with OSCP and mutual certificate authentication,
- For authentication OAuth, FIDO,
- For APIs: existing national APIs (e.g. FinTS in Germany) were originally designed for use in direct communication between payer and the payer’s bank. These standards are either proprietary or banking specific, and are not supporting third parties.
- The AIS functionality as well as the check for the availability of funds are not part of the design criteria of existing banking APIs. For example, the problem for an AIS is that -unlike the ASPSP - it has to pull account information. Furthermore, without specific protocol elements for account information updates - a functionality common email protocols support - the AIS would pull all available data and thus, would consume a lot of bandwidth and server performance.
- The availability of funds in respect to the requirements of the PSD2 is not part of known banking APIs and has to be designed. Because there is no direct communication channel to the PSU during the card usage – issued by a third party - it would be a complete new set of API infrastructure between the ASPSP and the card-issuing/processing PSP. Authentication methods with personalized user credentials issues by a third party (e-IDAS). Standards to mention: CEN and ETSI Standards on electronic signature.
- Setting up a new body to develop and maintain the current and future API initiatives will be a more time consuming and expensive approach
We consider the e-ID useful in the banking sector and/or in the corporate space. By contrast, in the consumer space it appears very difficult and expensive to use. Also it fails to provide the desired security level for several reasons (e.g. user experience/adoption, logistics, system governance, key management, incident management). Finally, the e-ID has been conceived in the context of e-government (public services and framework) as it can support efficiency in the public space. Out of that space, the current e-ID framework - as defined in the e-IDAS Regulation – is not sufficiently robust and flexible to serve as an efficient tool in support of customer authentication. We would advise against RTS mandating use of e-ID/e-signature in the context of SCA.
- Some of the e-IDAS Regulation tools could be useful to support the procedures for secure communication between the PSPs (AIS, PIS, and ASPSP). Also some concepts of the e-signature could be used for payer authentication methods.
However, e-ID/e-signatures are quite complex and require too much effort from the users that their adoption in the consumer space is highly unlikely. As an example, the HBCI standard in Germany has existed for more than two decades now: this signature-based hardware authentication provides for a poor user experience and shows a close to zero consumer acceptance. e-ID cards are another example of an inconvenient (or impossible, in the mobile environment) identification method for commercial applications. A huge amount of payments are not initiated from the consumer’s personal device. However hardware installations are not the best option and the current mobile centric trend make it very inconvenient for PSUs to carry signature hardware.
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.
Article 97(1) (c) is extremely broad: there is a potentially endless list of actions implying a risk of payment fraud or other abuses. Also, new categories of risk might arise as technology develops. Accordingly, we recommend the EBA RTS should be flexible and multi-faced, allowing PSPs to act based on transaction type and on assessment of the risk.Incidentally, we would like to stress that direct debit should be out of scope of strong customer authentication for transaction initiating: direct debit transactions are not initiated by the payer but by the payee. Accordingly, the direct debit risk model is inherently different from ‘push payments’ (i.e. payments initiated by the payer), for which the payer’s authentication is relevant.
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 does not necessarily have to be related to elements of a tangible nature, but can also be digitalized thanks to innovative technologies. Some examples are:- Mobile App
o Factor 1: PIN, Biometrics
o Factor 2: Possession evidence by cryptographic key, device fingerprinting
o Non-transferable cryptographic keys, unique device fingerprints, organizational constraints: preventing hand over device and PIN to a third party, PSU education and awareness, notification channel between PSU/PP.
- Mobile Phone
o Factor 1: PIN
o Factor 2: possession evidence by personal phone number
o organizational constraints: preventing hand over device and PIN to third party, PSU education and awareness, notification channel between PSU/PP.
- Biometric components in smartphones
o Rely on vendor mechanisms: e.g. Apple Touch ID
o Factor 1: Biometrics
o Factor 2: possession evidenced by cryptographic device key.
- Tokenization
o Factor 1: PIN
o Factor 2: Possession evidence by device bound token-based payment instrument.
We consider that it is not necessary that the PSU has the sole control of the possession elements, as these can be also held by the entity mandated by the PSU (e.g. by an AIS / PIS on behalf of the payer). The current definition of authentication in the PSD2 seems to support the principle that security credentials can be used by the PSP. (1 Art. 4. 29 of the PSD2: authentication" means a procedure which allows the payment service provider to verify the identity of a payment service user or the validity of the use of a specific payment instrument, including the use of the user’s personalised security credentials.)"
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?
Behaviour-based characteristics are extremely useful to detect fraud or other abuses for digital financial services. Behaviour-based characteristics and transaction patterns of the PSU are clearly traceable and can be extremely accurate when detected through advanced technologies. Behaviour-based characteristics have been successfully used by PSPs to assess risk, but they can also be valid forms of ‘passive authentication’, potentially even more effective than ‘active authentication’. Compared to static passwords, the trustworthiness of behaviour-based characteristics is equivalent to dynamic one-time passwords. Moreover, behaviour-based characteristics are not exposed to spoof and other social engineering.Therefore, we consider behaviour-based characteristics can be used very effectively in the context of SCA under the condition that the authentication system for the “inherence” elements is sufficiently accurate (e.g. providing a low crossover error rate and provided the transaction patterns are maintained constantly up to date).
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)?
Strong customer authentication for remote payments relies on a secure communication channel between ASPSP and PSU. Thus, the payment channel (e.g. the PSU uses a web browser for shopping and paying) has to be separated from the channel the PSU uses to enter/validate authentication data (e.g. via a SMS app in the mobile). Use of authentication hardware, supporting the network connection separation, will allow the physical separation of the two channels.However, using hardware to secure/separate communication channels poses the following major issues, depending on the PSU’s environment:
PSU cannot install/connect personal hardware on workplace equipment,
The handling of specific devices rely on PSU level of education/awareness,
Multi-step authentication needs PSU expertise,
Authentication methods have to be simple to prevent social engineering,
Low user adoption rate due to the inconvenience of having to carry additional devices.
Kindly note that we are unconvinced that the challenge is merely isolating the channels/ ensuring that the authentication elements are as independent as possible. In our view, effective solutions in this area must also meet the criteria of usability and convenience from the PSU’s perspective. A logical (software-based) separation of payment and authentication channel can be sufficiently secure (e.g. a mobile browser for shopping and paying, and an authentication app on the same device can be considered strong authentication) provided the software/ apps are isolated in a way that their security architectures don’t interfere.
Software-based authentication can also deploy new defence strategies in case of incidents/ vulnerabilities of the authentication process. Should a major incident require adjustments, logistics, development and certification processes of hardware-based authentication elements could preclude the availability of payment instruments for weeks.
Given the current trend toward mobile centric interaction in the digital finance, we would strongly advise against regulatory requirements mandating a separation of hardware token for authentication.
5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?
We are not persuaded of the actual benefits of SCA with dynamic linking. During the PSD2 negotiations the reasons supporting the introduction of dynamic linking have not been adequately addressed: as a consequence its objective and scope are still quite unclear. In fact, despite the PSD2 suggestion that it should apply to “electronic remote payment transactions” SCA with dynamic linking is actually usable only in limited circumstances.Linking transaction amount and payee implies accuracy of both data. Though the PSU might be aware of the transaction amount (yet, in some cases the amount might be unknown in advance) validating the name/IBAN of the payee is not always possible.2 Therefore, except in cases where the PSU enters the transaction data directly, the PSU will have to rely on the PSP for this data.
The PSD2 does not seem to clarify how the payee’s data will be protected and validated, especially for transactions initiated by TPPs.3 Also, it is unclear who is responsible for the dynamic linking (PIS,ASPSP or PSU?). We consider that both the ASPSP and the PSU could support the dynamic linking on a technical level. These are some of the possible implementations:
- On the ASPSP side a secured table assigns transaction data to the PSU’s authentication token ( e.g. a SMS token)
- On the PSU side an app assigns the transaction data to the PSU’s identity, (e.g. by a cryptographic hash or a digital signature).
However, SCA with dynamic linking is feasible only for transactions in which the PSU interacts directly with the PSP. Therefore, there are several different scenarios in which dynamic linking will not be possible. We would recommend the RTS to allow exemptions to the SCA with dynamic linking: not only there are more reliable and user friendly alternatives to it (e.g. PayPal deploys sophisticated technologies supporting validation of PSU’s identity and detection of early attempts of fraud, with very limited friction for users) but this requirement might be excessively burdensome in some cases (e.g. low risk transactions).
6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?
In our view there are no specific solutions fulfilling these objectives. There are several solutions allowing for different levels of independence and dynamic linking, which can be effective based on the specific transaction type/risk level. We would strongly advise against a ‘monolithic approach’, where a single security solution is mandated for the payments market, preventing PSPs from modulating their authentication response based on the risk assessment and customer profile. This approach would quite obviously also jeopardize innovation, apart from being a boon for fraudsters.With this said, below we list some of the solutions that, depending on the type of transaction, can be effective in ensuring independence and dynamic linking in the mobile environment:
- Mobile SMS token, if the mobile is used as second channel and shopping via PC/mobile browser + notification/validation via payments app/email,
- Mobile authentication app which is able to receive secured transaction data and interacts with PSU for confirmation,
- Mobile payments app, if the app is separated from shopping/paying channel (e.g. payment app is different from browser/in-app shopping) and app signs/hashs the transaction data with PSU specific key,
- Physical hardware token which is able to receive the transaction data/token from ASPSP, PISP or PSU-environment.
7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?
The clarifications suggested are very useful, and PayPal supports the EBA’s approach.We particularly appreciate clarifications on risk-based authentication, which is critical to stimulate wider users’ adoption and to ensure digital payment solutions are safe and user friendly for unproblematic transactions. Also, security methods based on a risk assessment can reduce attack vectors, thanks to the flexibility of the response and the context-specific features of the security tool. Finally, risk-based security enables improved incident management, due to a faster response to fraud risks and flexible adjustment of the authentication process.
With this said, we would recommend the RTS to mention the potential exemptions as a reference list only, which should not prevent other exemptions to be granted (based on a case-by-case assessment) by home state financial supervisors. This dynamic approach is needed not only to adequately stimulate EU innovation in the security field, but also to accommodate the constant changing patterns of online fraud and consumer behaviour (both driven by the adoption of new technologies).
8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?
Exemptions should take into consideration:- Risk structure of the underlying payment instrument,
- Risk structure of the Payment System / PSP,
- Context of the payment transaction and control measures,
- Use cases and transaction risk (e.g. low value, limits, organizational measures or legislation, limited fraud case, etc.).
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?
We support the approach suggested under paragraph 45 (a), (b), and (c). This is already part of PayPal’s risk mitigation systems, and we have successfully tested its effectiveness.For (a) and (b), in consideration of potential attacks to financial sources (attacks on the PSU side), an additional criterion could be the patterns of fraudulent financial insolvency. Such criteria can support early detection and consolidation of fraudulent financial flows. Another useful criterion could be the distributed patterns of transactions (attack wave patterns).
However, we respectfully recommend that the elements (a), (b) and (c) mentioned in paragraph 45 are not set as mandatory factors, i.e. PSPs should not be mandated to use only these elements when performing their risk assessment. As discussed in our response to question 7 above, a dynamic approach is needed to take into account innovation and developments in the fast changing digital ecosystem.
10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?
In general we consider the clarification suggested useful. However, we would like to stress that the diversity of authentication and security methods in the digital financial area is probably the strongest protection from a holistic perspective. Defining very specific technical security parameters could force PSPs to follow the same or few authentication methods. Fraudsters would then focus their effort to compromise a specific authentication method to reach a huge consumer segment. Also, regulators should consider that mandating any authentication method that is not sufficiently supported by a business/customer rationale might negatively impact PSPs’ business offer/user adoption, to the detriment of customers’ choice and competition in the payment market.11. What other risks with regard to the protection of users’ personalised security credentials do you identify?
We have identified other risks identified as follows:- Weak algorithms for generating user credentials,
- Physical access to hardware from personal environment,
- Social engineering,
- Hardware weakness and availability of hardware, connections, no fall back processes.
However risks are constantly arising as fraudsters continuously develop new targets and strategies while new customers’ patterns and technologies arise.
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 innovative solutions as follows:- FIDO standard,
- App/token based on cryptographically secured self-enrolment with activation codes.
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 have identified alternatives as follows:- Regular penetration testing based on standardized methodologies
- Certification only for critical infrastructures with high volume or high market impact
- Vendors of authentication software: certify the development process, rather than the software.
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?
We have identified the most likely segments as follows:- PSU,
- PSU Interface,
- Authentication method,
- Fall back processes,
- Enrolment process.
-
We have identified unlikely or unusual segments as follows:
- Transmission channel
- PSP online service
- PSP back-end
- PSP employees
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?
We broadly agree with the suggested approach and welcome the clarifications provided.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?
a) A “common standard” is only that if most PSPs implement that standard. In the context of PSD2 it is either mandated or adopted by PSPs with a sizeable user base (e.g. over 100.000). “Open” refers to standards developed and maintained by a stakeholder community as standardization bodies do (ISO, CEN, ETSI, etc.). Trade associations with stakeholder participation could be considered as standardization bodies (e.g. the EPC).b) TLS/SSL are technologies considered best practice to secure the communication without the need for a contract-based symmetric key exchange. The mutual validation of the party’s certificate implies trusted Certification Authorities and real-time certificate validation (e.g. via OCSP). This implies the secure provision of EBA’s register entries (the entities common name and certificate) to the communication partners.
Example: TLS/SSL are technologies considered best practice to secure the communication for ad-hoc communication. Symmetric key exchange could also be possible for contract-based communication
c) PIS:
- Establish mutual authenticated secure connection,
- Submit the transaction data,
- Link between transaction data and PSU is done by PIS, ASPSP or PSU, depending on the solution,
- Trigger/process the PSU authentication
- Get success/error message about payment order processing.
AIS:
- Establish mutual authenticated secure connection,- Trigger/progress the PSU authentication or provide permission for recurrent account information request,
- Receive all payment transaction data or update only,
- Receive account data and information about available data.
Availability of funds:
- Establish mutual authenticated secure connection,
- Submit the account id, amount and transaction reference,
- Receive confirmation message (yes/no) about availability of funds.
d) e) For a reliable service the API of ASPSP should be able to set limits for the number of times an account can be accessed, how many times a PIS/AIS/PSP can access an ASPSP. The mutual authentication should rely on real-time validation of keys e.g. OSCP. The EBA register should be secured and rely on hardened services.
f) PIS: The initiation of a SEPA credit transfer re-using as much as possible from the SEPA CT rulebook. Return messages based on ISO 20022. AIS: Messages based on ISO 20022, CAMT, no difference in scope and extent from the default online user interface. Availability of funds: Messages based on ISO 20022.
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 have identified suitable standards as follows:- For secure communication: TLS with OSCP and mutual certificate authentication,
- For authentication OAuth, FIDO,
- For APIs: existing national APIs (e.g. FinTS in Germany) were originally designed for use in direct communication between payer and the payer’s bank. These standards are either proprietary or banking specific, and are not supporting third parties.
- The AIS functionality as well as the check for the availability of funds are not part of the design criteria of existing banking APIs. For example, the problem for an AIS is that -unlike the ASPSP - it has to pull account information. Furthermore, without specific protocol elements for account information updates - a functionality common email protocols support - the AIS would pull all available data and thus, would consume a lot of bandwidth and server performance.
- The availability of funds in respect to the requirements of the PSD2 is not part of known banking APIs and has to be designed. Because there is no direct communication channel to the PSU during the card usage – issued by a third party - it would be a complete new set of API infrastructure between the ASPSP and the card-issuing/processing PSP. Authentication methods with personalized user credentials issues by a third party (e-IDAS). Standards to mention: CEN and ETSI Standards on electronic signature.
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)?
- Requirements have to be developed by industry standardization bodies through generally known and approved development criteria and processes (e.g. ISO, ETSI, CEN).- Setting up a new body to develop and maintain the current and future API initiatives will be a more time consuming and expensive approach
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.
We are quite sceptical of the actual usability of the e-IDAS Regulation in the context of payments authentication. Although the technology of digital signatures and cryptographic hashing is used in some banking authentication methods, it cannot be easily leveraged to become the customer identification method for payment authentication. The preconditions for signature based infrastructure with mutual validation of the authenticity of third parties (e.g. public key infrastructure) are excessively broad.We consider the e-ID useful in the banking sector and/or in the corporate space. By contrast, in the consumer space it appears very difficult and expensive to use. Also it fails to provide the desired security level for several reasons (e.g. user experience/adoption, logistics, system governance, key management, incident management). Finally, the e-ID has been conceived in the context of e-government (public services and framework) as it can support efficiency in the public space. Out of that space, the current e-ID framework - as defined in the e-IDAS Regulation – is not sufficiently robust and flexible to serve as an efficient tool in support of customer authentication. We would advise against RTS mandating use of e-ID/e-signature in the context of SCA.
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.
- We consider that usage of e-ID/e-signature might be helpful to address risks related to confidentiality and integrity of PSCs. We doubt this can be the case for PSC availability. In a decentralized approach, with high diversity of different authentication methods, the availability is much higher than in an environment based on a single concept.- Some of the e-IDAS Regulation tools could be useful to support the procedures for secure communication between the PSPs (AIS, PIS, and ASPSP). Also some concepts of the e-signature could be used for payer authentication methods.
However, e-ID/e-signatures are quite complex and require too much effort from the users that their adoption in the consumer space is highly unlikely. As an example, the HBCI standard in Germany has existed for more than two decades now: this signature-based hardware authentication provides for a poor user experience and shows a close to zero consumer acceptance. e-ID cards are another example of an inconvenient (or impossible, in the mobile environment) identification method for commercial applications. A huge amount of payments are not initiated from the consumer’s personal device. However hardware installations are not the best option and the current mobile centric trend make it very inconvenient for PSUs to carry signature hardware.