Response to consultation on RTS specifying the requirements on strong customer authentication and common and secure communication under PSD2
Go back
As you may expect from a card scheme, we are particularly focussed on the way that the requirements will apply to card payments (‘pull’ payments) as opposed to other types of payment. In this regard, the long-held understanding of the card industry is that card payments are viewed as initiated by the payee (i.e. the retailer) rather than by the payer (i.e. the cardholder). The rationale for this view is that, in order for a card payment to happen, the retailer requests, through its merchant acquirer, settlement from the issuer via the network of the relevant card scheme. The cardholder provides his or her consent for this process, but does not actually ‘initiate’ the payment. In contrast, for a ‘push’ payment such as a credit transfer, the payer initiates the payment without the need for the knowledge or involvement of the payee.
As the UK Cards Association and Payments UK have highlighted, PSD2 Recital 77 clearly also supports this interpretation in saying that “…payee transmits to the payment service provider payment orders for the collection e.g. of card payments or of direct debits...”
It appears to us that this distinction between ‘push’ and ‘pull’ payments is critical to the requirement for the application of SCA under Article 97 PSD2.
To agree with the established view that a card transaction is initiated by the payee would mean that Article 97(1)(b), which states that a PSP must apply SCA whenever a payer initiates an electronic payment transaction, should not capture card payments. The second consequence of accepting this view is that Article 97(2), which contains the requirement for dynamic linking of the transaction to the specific payee and amount, would also not be relevant to card payments because it only applies when Article 97(1)(b) applies.
Whilst this reading would mean that SCA would not be required for card payments in a traditional ‘bricks and mortar’ or ‘card present’ transaction, it would still allow for “remote” card payments – e.g. online or non-face-to-face transactions – to be caught under Article 97(1)(c) if the channel was one that could imply a risk of fraud or other abuse.
In our opinion, this is the better interpretation of the requirements of SCA under PSD2, and would minimise the unintended consequences of some of the provisions of the draft RTS that we have identified in this response.
Against that background, we note that paragraph 17 of the draft RTS states that card payments are payments that are initiated by the payer, like credit transfers. We strongly disagree with this for the reasons explained above and would be happy to provide you with further information if helpful to substantiate this reasoning. We agree with you, however, that direct debits are another example of a type of payment that is initiated by the payee.
To illustrate the difficulties caused by the approach taken in the draft RTS that card transactions are initiated by the payer, we list below some examples of the likely consequences.
• Chip and PIN may not suffice to meet the requirements of SCA, if the PIN does not comply with Article 3 (e.g. in relation to length, expiration time, non-repeatable characters etc.);
• Chip and signature may not suffice either as the two elements are not independent and the breach of one compromises the reliability of the other, per Article 6(1):
o Even if chip and PIN were compliant, EU issuers would be at risk of non-compliance for transactions taking place outside Europe, where the POS terminal infrastructure does not support PIN e.g. all travel to the USA this seems a disproportionate restriction of trade.
o EU issuers would be at risk of non-compliance for issuing these products to customers with disabilities who may not have the physical capability to provide a signature and/or enter chip details.
Since Article 1.3(e) would also apply to card present transactions where the transaction is authorised offline, or the PIN is verified offline, then all these transactions could not meet the SCA requirements because the relevant factors (i) to (v) could not be taken into account before the PSP’s final authorisation.
It is not clear to us how these outcomes would address security risks to a degree proportionate with the aim. Rather, it seems to us that these are the consequences of requirements which are too prescriptive in nature, and do not take adequately take into account the very different, complex operating environments (including outside the EU) in which EU card issuers need to be able to do business.
• We understand that the above view aligns with that of the UK Cards Association and Payments UK, and we support their response to this question.
To clarify in the final RTS that card transactions are initiated by the payee rather than the payer, and are therefore out of scope of Article 97(1)(b), would avoid the above detrimental consequences. It would, however, still mean that e-commerce and other ‘card not present’ types of transaction would be caught by Article 97(1)(c). SCA would need to be applied to those types of transactions, but without the need for the dynamic linking aspect, which seems a proportionate and sensible balance between customer convenience and the need to reduce incidences of payment fraud.
Rationale 19 b page 9
The EBA interprets that Article 74(2) of PSD2, which allows the payee or the payee’s PSP the option not to accept SCA, only applies during the short-time transitional period between the application date of PSD2 (13 January 2018) and the application date of the RTS under consultation (in October 2018 the earliest).
American Express is concerned that a RTS may not change the clearly-worded intention of the Level 1 text, and is particularly concerned that the interpretation here would also have a detrimental effect on e-commerce to and from Europe, forcing PSPs to decline vast numbers of transactions if they are to avoid breaching the SCA requirements.
We stand behind the response articulated by BZVi to this question, and agree that: Acquirers and merchants may elect not to apply SCA and to bear the risk of ultimate liability pursuant to Article 74(2) PSD2 instead.
• A payment transaction may also be authorised by the payer after the execution of a payment transaction (Article 64(1), sentence 2 PSD2).
If the intention of the legislators was that Article 74(2) should only apply for a transitional time period, this would have been reflected in Article 115 PSD2.
As an example of the type of consequences that could arise if the EBA maintains the interpretation expressed in the paper, this would have the consequence that (once the RTS were in effect), an EU card issuer would need to decline a transaction from an online merchant if the country where the merchant is registered is outside the EU did not support SCA. It is highly unlikely that this was the legislative intention and, if it was so, we understand this would need to have been more clearly expressed.
We set out below our comments on the specific draft provisions.
Article 1
If non remote card transactions are deemed to be caught by 97(1)(b) American Express would appreciate clarification:
• That magnetic stripe card transactions will still be allowed specifically for cards that have been issued outside Europe and cards issued to customers with disabilities;
• That fallback to other cardmember verification methods (CVM) from Chip and PIN after a technical issue would still be permitted
• On the requirements for ‘card present’ transactions which may not require any CVM (i.e. ‘offline’ transactions referred to above);
• Whether stand-in authorisation routines which are common to many issuers would meet SCA requirements as the PIN is not always validated.
Our primary request, however, is for clarification that card transactions are outside the scope of Article 97(1)(b) entirely.
Article 1(3)(b)
The requirement in Article 1(3)(b) which prevents disclosure of a failed authentication element to the PSU or PSP (e.g. wrong PIN) does not enable a customer friendly experience nor effective risk management. In certain cases it is useful to provide information on the cause of failure of SCA (failed PIN entry, CVV missing).
American Express suggests that this requirement be deleted or amended.
Article 1(3)(e)
These requirements are not all part of the authentication procedure for card payments, this list is a mixture of risk-based analysis and authorisation criteria. This is confusing the boundaries of authentication and authorisation and are over and above any PSD2 requirements.
Regulatory Technical Standards may only specify technical details and may not exceed the mandate given in the primary legislation. Thus, EBA and the European Commission are bound by the mandate in Article 98 of PSD2.Article 98 (1) (a) of PSD2 states that the RTS shall specify requirements of the strong customer authentication referred to in Article 97 (1) and (2) of PSD2. The term strong customer authentication" is legally defined in Article 4 no. 30 of PSD2 as an authentication based on the use of two or more elements categorised as knowledge, possession and inherence that are independent, in that the breach of one does not compromise the reliability of the others and is designed in such a way as to protect the confidentiality of the authentication data. The requirements listed in Article 1 (3) (e) of the Draft RTS are not authentication measures as these requirements concern additional safeguards by means of transaction monitoring but do not concern the actual authentication, i.e. identification, of the payment service user. In particular, these requirements do not concern the three SCA elements or their mutual independence. Thus, the mandate does not cover additional safeguards.
Article 1(3)(e)(ii)
These requirement are rather prescriptive. We would like to understand how a PSP can systematically detect malware when authenticating a remote transaction."
Clarification would be helpful on what constitute a valid authentication code. Would an SMS be considered as a channel that preserves the confidentiality, authenticity and integrity of the authentication code?
Currently there are mixed references in PSD2 and the draft RTS between:
(i) 'one time password' type authentication codes that are generated independently to the payment initiation process, input by the payer and providing an additional layer of authentication;
(ii) Electronic messaging, which is the output of the authentication process, requires no additional action from the payer and provides no additional authentication of the customer e.g. card cryptograms. The introduction of the former for ‘card present’ transactions would create an incremental requirement over an existing authorisation code.
Again here, we submit that there is a need to dissociate authentication from authorisation or, failing that, guidance is needed as to what would represent a valid authentication code.
We submit that the requirements on knowledge elements are overly prescriptive and as a consequence card PINs would not meet the technical standards.
Regarding the use of repeatable characters: a very strong password could contain repeatable characters in a mix use of lower and uppercase for example.
We submit that, if 90% of all online transaction can be risk-assessed for fraud and approved without SCA, then requiring systematic authentication is disproportionate. It will ultimately affect consumers by requiring them to be authenticated for every transaction.
The EBA could build SCA principles on certain online transactions, while providing for an exemption for recurring transactions, those below a low value threshold, or any transactions that are evaluated by appropriate risk-based analysis.
As an alternative regulatory approach, the EBA could set compulsory minimum fraud rate expectation for issuers, which would be achieved through both the application of SCA as well as individual risk-based models and technology, applied by PSPs, but under the regulators’ supervision
Article 8.1.b
The EBA clarified that proximity contactless transactions are exempt from SCA, including mobile contactless proximity payments. We agree with this clarification.
In our view, the EBA should not limit this exemption to low-value contactless transactions, however, but instead extend it also to low-value contact transactions as the risk profile and payment transaction technology are similar.
Currently the transaction limit is actually decided at market level and controlled by the terminal, not the issuer/payment device. The prescriptive 50 EUR transaction limit presents significant implementation challenges.
We are concerned that, in practice, the requirement that the cumulative amount may not exceed 150 EUR will not be possible to implement without significant industry change, particularly because:
• The use of cumulative counters varies depending on the implementation of the payment device payment application but, usually, cumulative counters are used to determine whether the transaction needs to be authorised on-line, not to determine if additional authentication is required.
• Due to the co-existence of multiple currencies in the EEA (and outside Europe, should the requirement apply outside of Europe), which makes it impossible for a payment device to handle all the necessary currency conversions.
• PSD2 uses existing practises for managing contactless payments as an example of user-friendly and accessible means of payment for low-risk payments. The definition of “low-risk” today is agreed at a country level and according to the operating environment e.g. retail versus transit Limits in one EU country therefore differ to those in another EU country, and will differ again to those a non-EU country. Sometimes there are also differences at a card scheme level, but the limits are consistently applied across payment service providers.
Clarification would also be helpful on whether an issuer may rely on authentication elements that are undertaken other than by the PSP directly, such as a biometric element on a phone be used for strong customer authentication.
Art.9.1.(a): We submit that “Data on personalised security credentials” should be defined or either the word “Data” should be deleted. In addition, a risk-based approach seems appropriate here as well. For example, there are arguments for permitting the user to be allowed a brief view of what he/she has keyed into an authentication field.
Art.17.1: We are not clear what is meant by secure bilateral identification between the payer’s device and payee’s accepting device. Is mutual authentication meant? The bulk of chip and PIN transactions are made without the identification on the terminal.
It is important to note that the EMV technology (including upcoming Next Generation specification) does not support the option for a payment device (e.g. card or mobile) to authenticate the payee’s acceptance device (e.g. POS terminal). What is supported is the capability for the payee’s acceptance device to authenticate the payment device as being genuine.
In EMV, the card does not authenticate the terminal. Such functionality is not needed from a payments security perspective, is operationally impractical and easily circumvented by criminals.
The proposals as drafted would require a major overhaul of the EMV technology that could necessitate a global replacement of existing terminals and cards.
Question 1: Do you agree with the EBA’s reasoning on the requirements of the strong customer authentication, and the resultant provisions proposed in Chapter 1 of the draft RTS?
American Express welcomes the opportunity to respond to the draft RTS on strong customer authentication (“SCA”) and common and secure communication under PSD2.As you may expect from a card scheme, we are particularly focussed on the way that the requirements will apply to card payments (‘pull’ payments) as opposed to other types of payment. In this regard, the long-held understanding of the card industry is that card payments are viewed as initiated by the payee (i.e. the retailer) rather than by the payer (i.e. the cardholder). The rationale for this view is that, in order for a card payment to happen, the retailer requests, through its merchant acquirer, settlement from the issuer via the network of the relevant card scheme. The cardholder provides his or her consent for this process, but does not actually ‘initiate’ the payment. In contrast, for a ‘push’ payment such as a credit transfer, the payer initiates the payment without the need for the knowledge or involvement of the payee.
As the UK Cards Association and Payments UK have highlighted, PSD2 Recital 77 clearly also supports this interpretation in saying that “…payee transmits to the payment service provider payment orders for the collection e.g. of card payments or of direct debits...”
It appears to us that this distinction between ‘push’ and ‘pull’ payments is critical to the requirement for the application of SCA under Article 97 PSD2.
To agree with the established view that a card transaction is initiated by the payee would mean that Article 97(1)(b), which states that a PSP must apply SCA whenever a payer initiates an electronic payment transaction, should not capture card payments. The second consequence of accepting this view is that Article 97(2), which contains the requirement for dynamic linking of the transaction to the specific payee and amount, would also not be relevant to card payments because it only applies when Article 97(1)(b) applies.
Whilst this reading would mean that SCA would not be required for card payments in a traditional ‘bricks and mortar’ or ‘card present’ transaction, it would still allow for “remote” card payments – e.g. online or non-face-to-face transactions – to be caught under Article 97(1)(c) if the channel was one that could imply a risk of fraud or other abuse.
In our opinion, this is the better interpretation of the requirements of SCA under PSD2, and would minimise the unintended consequences of some of the provisions of the draft RTS that we have identified in this response.
Against that background, we note that paragraph 17 of the draft RTS states that card payments are payments that are initiated by the payer, like credit transfers. We strongly disagree with this for the reasons explained above and would be happy to provide you with further information if helpful to substantiate this reasoning. We agree with you, however, that direct debits are another example of a type of payment that is initiated by the payee.
To illustrate the difficulties caused by the approach taken in the draft RTS that card transactions are initiated by the payer, we list below some examples of the likely consequences.
• Chip and PIN may not suffice to meet the requirements of SCA, if the PIN does not comply with Article 3 (e.g. in relation to length, expiration time, non-repeatable characters etc.);
• Chip and signature may not suffice either as the two elements are not independent and the breach of one compromises the reliability of the other, per Article 6(1):
o Even if chip and PIN were compliant, EU issuers would be at risk of non-compliance for transactions taking place outside Europe, where the POS terminal infrastructure does not support PIN e.g. all travel to the USA this seems a disproportionate restriction of trade.
o EU issuers would be at risk of non-compliance for issuing these products to customers with disabilities who may not have the physical capability to provide a signature and/or enter chip details.
Since Article 1.3(e) would also apply to card present transactions where the transaction is authorised offline, or the PIN is verified offline, then all these transactions could not meet the SCA requirements because the relevant factors (i) to (v) could not be taken into account before the PSP’s final authorisation.
It is not clear to us how these outcomes would address security risks to a degree proportionate with the aim. Rather, it seems to us that these are the consequences of requirements which are too prescriptive in nature, and do not take adequately take into account the very different, complex operating environments (including outside the EU) in which EU card issuers need to be able to do business.
• We understand that the above view aligns with that of the UK Cards Association and Payments UK, and we support their response to this question.
To clarify in the final RTS that card transactions are initiated by the payee rather than the payer, and are therefore out of scope of Article 97(1)(b), would avoid the above detrimental consequences. It would, however, still mean that e-commerce and other ‘card not present’ types of transaction would be caught by Article 97(1)(c). SCA would need to be applied to those types of transactions, but without the need for the dynamic linking aspect, which seems a proportionate and sensible balance between customer convenience and the need to reduce incidences of payment fraud.
Rationale 19 b page 9
The EBA interprets that Article 74(2) of PSD2, which allows the payee or the payee’s PSP the option not to accept SCA, only applies during the short-time transitional period between the application date of PSD2 (13 January 2018) and the application date of the RTS under consultation (in October 2018 the earliest).
American Express is concerned that a RTS may not change the clearly-worded intention of the Level 1 text, and is particularly concerned that the interpretation here would also have a detrimental effect on e-commerce to and from Europe, forcing PSPs to decline vast numbers of transactions if they are to avoid breaching the SCA requirements.
We stand behind the response articulated by BZVi to this question, and agree that: Acquirers and merchants may elect not to apply SCA and to bear the risk of ultimate liability pursuant to Article 74(2) PSD2 instead.
• A payment transaction may also be authorised by the payer after the execution of a payment transaction (Article 64(1), sentence 2 PSD2).
If the intention of the legislators was that Article 74(2) should only apply for a transitional time period, this would have been reflected in Article 115 PSD2.
As an example of the type of consequences that could arise if the EBA maintains the interpretation expressed in the paper, this would have the consequence that (once the RTS were in effect), an EU card issuer would need to decline a transaction from an online merchant if the country where the merchant is registered is outside the EU did not support SCA. It is highly unlikely that this was the legislative intention and, if it was so, we understand this would need to have been more clearly expressed.
We set out below our comments on the specific draft provisions.
Article 1
If non remote card transactions are deemed to be caught by 97(1)(b) American Express would appreciate clarification:
• That magnetic stripe card transactions will still be allowed specifically for cards that have been issued outside Europe and cards issued to customers with disabilities;
• That fallback to other cardmember verification methods (CVM) from Chip and PIN after a technical issue would still be permitted
• On the requirements for ‘card present’ transactions which may not require any CVM (i.e. ‘offline’ transactions referred to above);
• Whether stand-in authorisation routines which are common to many issuers would meet SCA requirements as the PIN is not always validated.
Our primary request, however, is for clarification that card transactions are outside the scope of Article 97(1)(b) entirely.
Article 1(3)(b)
The requirement in Article 1(3)(b) which prevents disclosure of a failed authentication element to the PSU or PSP (e.g. wrong PIN) does not enable a customer friendly experience nor effective risk management. In certain cases it is useful to provide information on the cause of failure of SCA (failed PIN entry, CVV missing).
American Express suggests that this requirement be deleted or amended.
Article 1(3)(e)
These requirements are not all part of the authentication procedure for card payments, this list is a mixture of risk-based analysis and authorisation criteria. This is confusing the boundaries of authentication and authorisation and are over and above any PSD2 requirements.
Regulatory Technical Standards may only specify technical details and may not exceed the mandate given in the primary legislation. Thus, EBA and the European Commission are bound by the mandate in Article 98 of PSD2.Article 98 (1) (a) of PSD2 states that the RTS shall specify requirements of the strong customer authentication referred to in Article 97 (1) and (2) of PSD2. The term strong customer authentication" is legally defined in Article 4 no. 30 of PSD2 as an authentication based on the use of two or more elements categorised as knowledge, possession and inherence that are independent, in that the breach of one does not compromise the reliability of the others and is designed in such a way as to protect the confidentiality of the authentication data. The requirements listed in Article 1 (3) (e) of the Draft RTS are not authentication measures as these requirements concern additional safeguards by means of transaction monitoring but do not concern the actual authentication, i.e. identification, of the payment service user. In particular, these requirements do not concern the three SCA elements or their mutual independence. Thus, the mandate does not cover additional safeguards.
Article 1(3)(e)(ii)
These requirement are rather prescriptive. We would like to understand how a PSP can systematically detect malware when authenticating a remote transaction."
Question 2: In particular, in relation to the “dynamic linking” procedure, do you agree with the EBA’s reasoning that the requirements should remain neutral as to when the “dynamic linking” should take place, under the conditions that the channel, mobile application, or device where the information about the amount and the payee of the transaction is displayed is independent or segregated from the channel, mobile application or device used for initiating the payment, as foreseen in Article 2.2 of the draft RTS.
We agree with the EBA that the dynamic linking requirements should remain neutral, however while the channel or mobile application could be segregated, it would be helpful if the EBA could clarify that refers to a logical segregation and not a hardware separation e.g. two mobile phones.Clarification would be helpful on what constitute a valid authentication code. Would an SMS be considered as a channel that preserves the confidentiality, authenticity and integrity of the authentication code?
Currently there are mixed references in PSD2 and the draft RTS between:
(i) 'one time password' type authentication codes that are generated independently to the payment initiation process, input by the payer and providing an additional layer of authentication;
(ii) Electronic messaging, which is the output of the authentication process, requires no additional action from the payer and provides no additional authentication of the customer e.g. card cryptograms. The introduction of the former for ‘card present’ transactions would create an incremental requirement over an existing authorisation code.
Again here, we submit that there is a need to dissociate authentication from authorisation or, failing that, guidance is needed as to what would represent a valid authentication code.
Question 3: In particular, in relation to the protection of authentication elements, are you aware of other threats than the ones identified in articles 3, 4 and 5 of the draft RTS against which authentication elements should be resistant?
Article 3We submit that the requirements on knowledge elements are overly prescriptive and as a consequence card PINs would not meet the technical standards.
Regarding the use of repeatable characters: a very strong password could contain repeatable characters in a mix use of lower and uppercase for example.
Question 4: Do you agree with the EBA’s reasoning on the exemptions from the application of Article 97 on strong customer authentication and on security measures, and the resultant provisions proposed in Chapter 2 of the draft RTS?
Article 98(2)(a) of PSD2 mandates the EBA to adopt “risk-based requirements” in relation to SCA, which take into account a number of competing interests, including but not limited to “allowing for the development of user-friendly, accessible and innovative means of payment” (Article 98(2)(e)). The risk-based requirements should factor in the level of risk involved in the service, the amount and/or recurrence of the transaction, and the relevant payment channel used (Article 98(3)).We submit that, if 90% of all online transaction can be risk-assessed for fraud and approved without SCA, then requiring systematic authentication is disproportionate. It will ultimately affect consumers by requiring them to be authenticated for every transaction.
The EBA could build SCA principles on certain online transactions, while providing for an exemption for recurring transactions, those below a low value threshold, or any transactions that are evaluated by appropriate risk-based analysis.
As an alternative regulatory approach, the EBA could set compulsory minimum fraud rate expectation for issuers, which would be achieved through both the application of SCA as well as individual risk-based models and technology, applied by PSPs, but under the regulators’ supervision
Article 8.1.b
The EBA clarified that proximity contactless transactions are exempt from SCA, including mobile contactless proximity payments. We agree with this clarification.
In our view, the EBA should not limit this exemption to low-value contactless transactions, however, but instead extend it also to low-value contact transactions as the risk profile and payment transaction technology are similar.
Currently the transaction limit is actually decided at market level and controlled by the terminal, not the issuer/payment device. The prescriptive 50 EUR transaction limit presents significant implementation challenges.
We are concerned that, in practice, the requirement that the cumulative amount may not exceed 150 EUR will not be possible to implement without significant industry change, particularly because:
• The use of cumulative counters varies depending on the implementation of the payment device payment application but, usually, cumulative counters are used to determine whether the transaction needs to be authorised on-line, not to determine if additional authentication is required.
• Due to the co-existence of multiple currencies in the EEA (and outside Europe, should the requirement apply outside of Europe), which makes it impossible for a payment device to handle all the necessary currency conversions.
• PSD2 uses existing practises for managing contactless payments as an example of user-friendly and accessible means of payment for low-risk payments. The definition of “low-risk” today is agreed at a country level and according to the operating environment e.g. retail versus transit Limits in one EU country therefore differ to those in another EU country, and will differ again to those a non-EU country. Sometimes there are also differences at a card scheme level, but the limits are consistently applied across payment service providers.
Question 5: Do you have any concern with the list of exemptions contained in Chapter 2 of the draft RTS for the scenario that PSPs are prevented from implementing SCA on transactions that meet the criteria for exemption?
We have concerns that currently mobile proximity contactless payments are being secured by biometric and possession elements which gives PSU great security confidence. Under the mandatory exemption proposed, these SCA method will become illegal. Is this the intention?Clarification would also be helpful on whether an issuer may rely on authentication elements that are undertaken other than by the PSP directly, such as a biometric element on a phone be used for strong customer authentication.
Question 6: Do you agree with the EBA’s reasoning on the protection of the confidentiality and the integrity of the payment service users’ personalised security credentials, and the resultant provisions proposed in Chapter 3 of the draft RTS?
We consider it important that this area of security is harmonised with security methodology like PCI, and it seems that the certification processes of PCI could be a way to meet the requirements here.Art.9.1.(a): We submit that “Data on personalised security credentials” should be defined or either the word “Data” should be deleted. In addition, a risk-based approach seems appropriate here as well. For example, there are arguments for permitting the user to be allowed a brief view of what he/she has keyed into an authentication field.
Question 7: Do you agree with the EBA’s reasoning on the requirements for common and secure open standards of communication for the purpose of identification, authentication, notification, and information, and the resultant provisions proposed in Chapter 4 of the draft RTS?
American Express agrees with the use of secure and open standards, specifically PCI.Art.17.1: We are not clear what is meant by secure bilateral identification between the payer’s device and payee’s accepting device. Is mutual authentication meant? The bulk of chip and PIN transactions are made without the identification on the terminal.
It is important to note that the EMV technology (including upcoming Next Generation specification) does not support the option for a payment device (e.g. card or mobile) to authenticate the payee’s acceptance device (e.g. POS terminal). What is supported is the capability for the payee’s acceptance device to authenticate the payment device as being genuine.
In EMV, the card does not authenticate the terminal. Such functionality is not needed from a payments security perspective, is operationally impractical and easily circumvented by criminals.
The proposals as drafted would require a major overhaul of the EMV technology that could necessitate a global replacement of existing terminals and cards.