Response to discussion on RTS on strong customer authentication and secure communication under PSD2

Go back

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.

I. General considerations

1. Payment transactions covered within the scope of PSD-2

Prior to discussing specific questions raised by EBA, emphasis must be given to the fact that the different payment transactions, as covered under the scope of the PSD-2, need to be treated differently due to their material difference in nature:

a) Credit transfer payment transactions are characterized by a bilateral legal and technical link between the payment service user (PSU) and his payment service provider (PSP). In a credit transfer transaction, the transaction is limited to the instruction of the PSU to his PSP. The PSP, in this simple bilateral relation, has an unlimited capacity of agreeing on specific legal terms and conditions with his PSU, and he is hereby also enabled to require the use of specific authentication methods and personal security credentials (PSC) as a prerequisite of accepting a credit transfer instruction. Hence, the PSP is completely in control of the legal and technical link with his PSU.

b) The opposite applies, however, in a card-based transaction which does not only involve two parties – such as in aforementioned credit transfer – but five parties as a multi-lateral payment transaction, which is characterized by the fact that each PSP involved in such transaction by virtue of nature only controls a limited part of his legal and technical links to his specific PSU, further depending on the function of the PSP whether he acts as credit card issuer or credit card acquirer. As Annex 1 to this statement of the IK, we attach a graphical chart, displaying the five parties involved in a typical card-based transaction (credit card issuer, credit card holder/PSU1, merchant/PSU2, credit card acquirer and credit card scheme).

c) Opposite to a bank, which offers online banking services with online credit transfers, a credit card issuer does not have autonomy to define for himself on the PSCs to be offered and to be used by his PSU, but the credit card issuer is completely dependent on the authentication methods and types of PSCs established and defined by the international credit card schemes, such as VISA or MasterCard. The same applies for credit card acquirers, which, again, can only offer authentication features which are existing and made available by credit card schemes.

d) Consequently, it is required to apply a differentiation between credit transfer transactions on the one hand and card-based transactions on the other hand. A regulated PSP in credit card business can only be responsible from a PSD-2 regulatory perspective, if specific authentication methods - as required by EU-regulatory authorities – are available for use within credit card schemes.

EBA, consequently, should consider to only impose specific duties on credit card issuers and credit card acquirers, if and to the extent those required technical features, either in authentication methods or processes, are available within and offered by the international credit card schemes.


Opposite to regulated PSPs, such as issuers or acquirers, payment card schemes are not subject to PSD-2-regulated supervision by member states’ financial services regulation, but only subject to the supervision of the payment services market by the European Central Bank (ECB) supported by the Eurosystem. Within this responsibility as a payment scheme operator, the international credit card schemes already launched the PCI DSS (Payment Card Industry Data Security Standard) with security requirements applicable for credit card issuers, acquirers and their service providers. EBA, consequently, should closely liaise with the ECB in order to ensure an adequate and synchronized requirement of authentication methods and processes within ECB’s supervision over payment systems on the one hand and EBA’s regulatory mandate over regulated PSD-2 PSPs on the other hand.

e) Furthermore, a credit card issuer does not hold any contractual relationships with a merchant who accepts a credit card payment. Consequently, a credit card issuer can only apply a SCA with his PSU, if the card payment accepting merchant also supports a SCA on his side. If the merchant decides not to apply SCA, the credit card issuing PSP does not have any legal means to force the merchant to apply SCA. Consequently – and again opposite to credit transfers operated by banks – credit card issuers cannot be subject to a comprehensive regulatory responsibility to apply SCA in an electronic remote card-based transaction, since the contracting between the PSU and the merchant is again beyond any control of the credit card issuer.

The same applies for credit card acquirers, which do not hold any contractual relationship with the cardholder/PSU. Consequently, a credit card acquirer can only apply and accept a SCA with his merchant/PSU, if the card payment initiating cardholder also applies a SCA on his side.

f) Aforementioned very material differences between credit transfer and card-based transactions call for a sophisticated differentiation by EBA between those payment transactions while drafting the RTS, including accurate and adequate use of terminology with respect to definitions of interactions between the different parties involved.

2. Development of innovative security solutions

EBA should feel encouraged to refrain from providing technical security prescriptions which may be too narrow in consideration of up-coming security solutions. If technical prescriptions are too static and narrow, risk is given that the achieved overall security level may quickly be old-fashioned, if not to say with increasing risk implied. This particularly holds true, if security requirements defined in detail by prudential regulation are not flexible enough to also include future developments of security tools and processes. Risk is given that an elaborate technical standard based on a 2013 (PDS-2’s first draft) and 2016 security philosophy with a two-way security requirement remains not flexible enough to also include up-coming industry standards with a better trade-off between security requirements, consumer protection and convenience and payment innovations.

3. Interaction with stakeholders

At the review of EBA’s Discussion Paper, the IK came to the conclusion that a technical expert hearing hosted by EBA would be the most helpful way to better explain in person rather than in writing how different security and authentication aspects, particularly in terms of innovative security and payment features, interact and are worth being considered. Thus, EBA meetings or hearings with technical experts in modern mobile communication and its interaction with card payments and security features provided by the international card schemes may be a good way forward to achieve all regulatory and innovative objectives of a modern pan-European payment landscape.

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?

a) It can be expected that over the next few years customers will be able to choose between a wide range of physical possession elements as connected objects to web-based communication, e.g. watches, glasses, cars, household appliances, etc.

b) Beyond possession of physical goods, however, EBA should in fact acknowledge that the notion of “possession” should not only address physical items, which can be “held in your hand”, but also specific data, which – as a common characteristic of “possession” - may also be “lost” or “damaged”. This particularly holds true for encryption technologies which make use of encrypted data packages, tokens or block chain technology which may be linked to other security features or even processes in the backbone of web-based or mobile communication networks. Those data may be valuable security credentials, which are not accessible or usable “by knowledge” and are not biologically inherent to the payment user. Since data must certainly be electronically stored anywhere on data mediums, not only those mediums, but also data may be lost or damaged.

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?

NA

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) With respect to the criteria for SCA, as prescribed in art. 98 para. 2 PSD-2, EBA correctly points out in its Discussion Paper that while requiring SCA, “technology and business-model neutrality” must be ensured and “the development of user-friendly, accessible and innovative means of payment” must be allowed.

Correctly speaking, a card-based payment with a mobile device, including an embedded “electronic” credit card contains more than two security criteria, which is (i) the possession of the mobile device, (ii) the possession of the SIM-card and (iii) knowledge of the PIN, providing access to the device. With respect to a “PIN”, awareness must be given to the fact that different PIN-security architectures may apply, depending on the payment product and the mobile device. There is the standard mobile device-PIN, which is allotted to accessing the device and which is generally stored on the device. Further, the global open standard “Mobile Connect” supported by GSMA, specifically enables consumers to authenticate sensible transactions, like accessing payment accounts or initiating payments. Security of the mobile device is provided by the mobile network by means of a two-way communication and business process which disables transactions in cases of thefts, losses or SIM swaps with an available security assurance level equal to LoA 2-4 under the eIDAS regulation.

If a mobile device, duly secured by a PIN, is lost or stolen, the device holder only loses his ability to use the device, but the PSC of the PSU is not automatically compromised. Since the mobile connect standard PIN is not readable or otherwise identifiable on the mobile device, but securely encrypted on the SIM with a SIM applet, the two required criteria for a SCA, such as possession (mobile device) and knowledge (PIN) are still independent.
Furthermore, consistency with the e-IDAS Regulation approach should be achieved. e-IDASs treats mobile devices and business processes as separate elements, distinguishing between mobile device and the mobile eco-system (i.e. the mobile device, the mobile network and the mobile operators’ business processes) to ensure communication and authentication security.

This also complies with a risk-based assessment of the existing mobile network security, where the mobile network has knowledge of the linked use of the mobile phone, the SIM and the phone number (MSISDN). The combination of these three criteria is securely stored in the mobile network, which is not accessible from outside. Whenever a mobile device is activated, the mobile network is aware of the interlinking of the device, the phone number and the SIM. If a device is used with a different SIM, the network can immediately identify this new interlinking and can take appropriate and risk-mitigating actions, if this occurrence may be interpreted as an attempt of fraud.

b) In a nutshell, EBA should reconsider that the use of mobile devices for an electronic credit card payment shall be accepted as two independent sets of authentication features (possession and knowledge), unless the mobile device is not secured by a PIN or a PIN – in a theoretical assessment – is identifiable for every “possessor” of the mobile device. In standard cases, however, the IK is of the opinion that the PIN is not identifiable from the mobile device and – consequently – is an authentication feature independent from the possession of the mobile device.

5. Which challenges do you identify for fulfilling the objectives of strong customer authentication with respect to dynamic linking?

The dynamic link requirement (as described in PSD2) should recommendably be specified especially to explain what information shall be linked and how the link shall be created. As outlined above, I.1., particular attention needs to be given to card-based payments with five stakeholders involved in every individual payment transaction and the need to acknowledge that also dynamic linking in card-based payments requires inter-operability between all stakeholders as defined by the international card schemes.

Again, in order to promote and facilitate innovative solutions, these specifications should not describe technical solutions in detail but functional approaches which remain open and flexible for up-coming technical solutions which are not yet conceivable.

6. In your view, which solutions for mobile devices fulfil both the objective of independence and dynamic linking already today?

Beyond known solutions, which dynamically link transactions with specific authentication codes on mobile devices (see also questions no. 4 and 5), also HCE (Host Card Emulation) requirements specified by the payment card schemes may be seen as another good example of a software-based solution to enable mobile devices for NFC (Near Field Communication) payments by using cryptographic resources in order to create a unique and non replayable link between authentication and transaction.

7. Do you consider the clarifications suggested regarding the potential exemptions to strong customer authentication, to be useful?

a) Fair competition with three party payment schemes required

While the IK supports EBA’s approach in sect. 42/D that transfers “between two accounts of the same PSU held at the same PSP” may be viewed as an excluded low-risk transaction, it must be stressed that within the international payment services market this exemption is of a very high importance in order to avoid distortion of competition between different payment systems.

Only if in a three party payment scheme, such as PayPal, the PSU transfers funds from one account to another account held by him/the same PSU, is it acceptable and under a risk-based approach justifiable to exclude such transactions from the requirements for SCA.

In order to avoid distortion of competition, EBA should feel encouraged to clearly point out that it shall not be possible to refrain from applying SCA within “dedicated networks”, if funds are transferred from one PSU to a different person, the payee, who also holds an account or other contractual relationship with a three-party payment scheme operator, such as PayPal.

The risk of a misuse or fraud of PSCs within three party schemes is the same compared to a classical card-based transaction, since a payer in case of fraud or misuse of his PSCs runs the risk of losing his funds to a third party, even if this third party is also participating in the same payment scheme. Consequently, EBA should feel encouraged to clarify that different payment systems and instruments with the same risk implied should be subject to the same regulatory framework under PSD-2, including SCA requirements.

b) Transaction risk analysis/commercial business

The IK also supports EBA’s approach to exclude low-risk transactions based on a transaction risk analysis. Particularly in commercial business with commercial entities holding credit cards as PSUs for payment purposes, awareness must be given to the fact that the risk of fraud or misuse of commercial cards is a very rare phenomenon compared to fraud or misuse of payment cards of consumers. With commercial or corporate cards, additional control environments on the corporate entity side apply, including controls over a limited range of payment acceptants, particularly in the travel and accommodation market, which leads to reduced figures of misuse or fraud with the use of commercial or corporate cards.

Consequently, it may be advisable to clarify in EBA‘s upcoming RTS that the use of commercial cards for card-based payments – again subject to an individual transaction risk analysis of the PSP – may be seen as one example case of a low risk transaction, which may be exempted by the PSP from the application of SCA requirements.

c) Transaction or product risk analysis and technological neutrality

The regulatory requirement of SCA under PSD-2 should not hamper technological progress and innovation and should – as already pointed out by EBA – be technologically neutral. In this respect, the strict limitation to a SCA pursuant to art. 4 no. 30 PSD-2 with a two-way factor authentication may be too restrictive in light of upcoming new technologies.

In securities markets, e.g. ESMA already held a public hearing in London in January with respect to the use of block chain technology in securities clearing and settlement business. It cannot be excluded that block chain (only as an example) or comparable technology might also be an innovative solution in the future for payment services.
Furthermore, innovative solutions for online business with the use of credit cards with so-called “token” as a one-time payment authentication data might enable payments for consumers and merchants in a much easier and more secure way and should not be excluded from scratch in terms of standardized SCA requirements. The same applies for aforementioned HCE-requirements for NFC-payments and e-IDAS token specifications, as contributed by the German and French IT security agencies BSI and ANSSI, which take the development of token-based solutions for authentication processes into consideration. Consequently, in terms of discussing transaction or product risk analysis as basis for low-risk transactions or processes, EBA should feel encouraged to also allow payment services providers to apply upcoming new technologies, if in the PSP’s transaction risk assessment the use of those technologies also qualifies as low-risk transactions.

This risk-based approach also needs to include a combination of other authentication standards – with a lower security level than SCA – for transactions with a lower risk level rather than a “black or white” approach with no or full SCA applied. EBA already pointed out in its EBA guidelines 12/2014 on the security of internet payments title II, 2.1. that risk assessments should consider all aspects of transaction risk characteristics and security levels by different authentication methods. Consequently, in consideration of SCA-exemptions, payment services providers should also be enabled to apply other levels of authentication with a perspective on specific transaction risk aspects.

Otherwise, risk is given that the development of innovative and flexible payment solutions might be hindered by static regulatory standards.

8. Are there any other factors the EBA should consider when deciding on the exemptions applicable to the forthcoming regulatory technical standards?

To ensure adequate transparency and to avoid regulatory arbitrage, it would be recommendable to publish a list of exemptions with detailed definitions and - particularly with respect to card-based payment - clarifications which institution shall be responsible for the decision and the application of exemptions (e.g. the issuer and/or the acquirer in the course of processing card-based payments).

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?

NA

10. Do you consider the clarification suggested regarding the protection of users personalised security credentials to be useful?

The RTS should clearly differentiate between the rights of the data subject/PSU and the data security aspects as operational requirements. Furthermore, vague terms (e.g. “privacy of data”) which do not clearly comply with EU-regulatory definitions should be avoided.

11. What other risks with regard to the protection of users’ personalised security credentials do you identify?

NA

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?

a) Innovative proposals

While establishing security requirements for the enrolment process of PSCs, also innovative, including secure mobile enrolment processes should be promoted. As a means of innovative PSC enrolment, the issuing of PSC via ATMs should also be considered. With a payment card applied at an ATM, a unique code (possibly in the format of a QR-code) may be generated and used to enrol a device or a profile on a device. Such innovative solutions will not only be cost and time-saving both for the payment industry and card holders, but also more secure compared to legacy enrolment processes.

b) National digital identity platforms

A range of new digital solutions for providing identification services are being developed. For example, national new digital identity platforms, as defined by the e-IDAS regulation, could be used as an adequate and workable solution to deploy or support secure enrolment processes.

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?

NA

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?

NA

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?

NA

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?

NA

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?

NA

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)?

NA

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.

NA

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.

NA

Name of organisation

Interessengemeinschaft Kreditkartengeschäft (IK)

Please select which category best describes you and/or your organisation.

[ "]"

Please select which category best describes you and/or your organisation.

[ "]"