PCI Watch

Tracking changes across the Payment Card Industry

SB nº 189: EMV® Book C-4

v1.0 Specification Bulletins
Contactless

EMV® Specification Bulletin No. 189 December 2016 EMV Book C-4 This Specification Bulletin contains an update to EMV Book C-4.

Applicability

This Draft Specification Bulletin applies to:

  • [EMVC4-2.5] EMV Contactless Specifications for Payment Systems, Book C-4, Kernel 4 Specification, Version 2.5, March 2015.
  • [EMVC4-2.6] EMV Contactless Specifications for Payment Systems, Book C-4, Kernel 4 Specification, Version 2.6, May 2016.

Effective Date

The changes in this bulletin will be effective from its publication.

Related Documents

None

Description

This Specification Bulletin defines changes to address a number of errata in EMV Book C-4, Version 2.5 [EMVC4-2.5] and Version 2.6 [EMVC4-2.6]. The changes in this bulletin have been categorized by the functionality specified in the relevant sections found in the EMV Book C-4 specification. Each specification change is defined by the content of the relevant part as is, followed by the content to be in the updated specification. Any respective differences in the content to be have been underlined accordingly.

countries.

A. Processing restrictions A.1. Changes to 7.2.1 Apply Dynamic Transaction Limits The following amendment is applicable to [EMVC4-2.5] only: As Is: If the ‘Contactless Application Not Allowed’ indicator is set to 1 and the card supports an alternative interface, the Kernel shall return control to Entry Point with a Final Outcome Try Another Interface with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A N/A Yes Message Identifier: '18' (“Please insert/swipe card”) Status: Processing Error: Conditions for use of contactless not satisfied Hold Time: 0 Language Preference No No No Contact Chip N/A N/A Zero To Be: If the ‘Contactless Application Not Allowed’ indicator is set to 1 and the card supports an alternative interface, the Kernel shall return control to Entry Point with a Final Outcome Try Another Interface with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present N/A N/A N/A Yes Message Identifier: '1D' (“Please insert card”) Status: Processing Error: Conditions for use of contactless not satisfied Hold Time: 0 Language Preference No No

countries.

Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout No Contact Chip N/A N/A Zero B. Cardholder Verification B.1. Changes to 8.2.3 CVM List Processing The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]. CVM condition codes should not be restricted to ‘00’, ‘02’ or ‘03’ only. As Is: Requirements – CVM List Processing 8.2.3.1a If all of the following are true:

  • The Reader CVM Required Limit Exceeded indicator is set.
  • The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b).
  • The CVM List is present and contains at least one entry. Then, the following steps are carried out: 1. The reader shall examine the first CVM in the CVM List. 2. If the reader supports the CVM, and the Condition Code of the CVM method is equal to ‘00’, ‘02’ or ‘03’, then the reader shall save the matching CVM and return the CVM recorded in the Final Outcome. 3. Else if another CVM is present in the CVM List, then the reader shall repeat the process in this requirement from step 2, using the next CVM in the CVM List. To Be: Requirements – CVM List Processing 8.2.3.1a If all of the following are true:
  • The Reader CVM Required Limit Exceeded indicator is set.
  • The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b).
  • The CVM List is present and contains at least one entry. Then, the following steps are carried out: 1. The reader shall examine the first CVM in the CVM List. 2. If the reader supports the CVM, and the Condition Code of the CVM is satisfied, then the reader shall save the matching CVM and return the CVM recorded in the Final Outcome. 3. Else if another CVM is present in the CVM List, then the reader shall repeat the process in this requirement from step 2, using the next CVM in the CVM List. countries. B.2. Changes to 8.2.5 Cardholder Verification Unable To Complete over Contactless Interface The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]. CVM Results must be set according to EMV ICC Specifications, Version 4.3, Book 4, Sec 6.3.4.5, instead of being explicitly set to ‘3F 00 01’, in order to cater for the different outcomes from CVM processing. As Is: If Cardholder Verification cannot be performed over the Contactless interface, then: The reader shall set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. CVM Results to '3F 00 01'. To Be: If Cardholder Verification cannot be performed over the Contactless interface, then: The reader shall set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. CVM Results set as per EMV4.3iv section 6.3.4.5. The following amendment is applicable to [EMVC4-2.5] only: As Is: If the transaction is taking place in EMV mode and the reader has a Contact interface then: If the Card Interface and Payment Capabilities Byte 1 Bit 6 is 1b, ‘Contact EMV Interface supported’, or if Card Interface and Payment Capabilities is not present, then the kernel returns control to Entry Point, passing a Final Outcome of Try Another Interface with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present N/A N/A N/A Yes
  • Message Identifier: '18' (“Please insert/swipe card”)
  • Status: Processing Error: Conditions for use of contactless not satisfied
  • Hold Time: 0
  • Language Preference No countries. Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout No No Contact Chip N/A N/A Zero To Be: If the transaction is taking place in EMV mode and the reader has a Contact interface then: If the Card Interface and Payment Capabilities Byte 1 Bit 6 is 1b, ‘Contact EMV Interface supported’, or if Card Interface and Payment Capabilities is not present, then the kernel returns control to Entry Point, passing a Final Outcome of Try Another Interface with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A N/A Yes
  • Message Identifier: '1D' (“Please insert card”)
  • Status: Processing Error: Conditions for use of contactless not satisfied
  • Hold Time: 0
  • Language Preference No No No Contact Chip N/A N/A Zero countries. The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]: As Is: Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.1a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). There is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities Byte 1 Bit 6 is set to 1b, ‘Contact EMV Interface supported’. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results to '3F 00 01'. 8.2.5.2a Return a Final Outcome of Try Another Interface. If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). There is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities element is not present. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results to '3F 00 01'. Return a Final Outcome of Try Another Interface. countries. Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.3a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). There is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities element Byte 1 Bit 6 is set to 0b, ‘Contact EMV Interface supported’. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results to '3F 00 01'. 8.2.5.4a The transaction continues with Terminal Risk Management. If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). There is not a mutually supported CVM across the contactless interface The transaction is taking place in EMV mode and the reader does not have an alternative interface Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results to '3F 00 01'. The transaction continues with Terminal Risk Management. countries. Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.5a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. The card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b). There is not a mutually supported CVM across the contactless interface The transaction is taking place in mag-stripe mode Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results to '3F 00 01'. The transaction continues with Terminal Risk Management. To Be: Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.1a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. Either the card does not support Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 0b) or the card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b) and there is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities Byte 1 Bit 6 is set to 1b, ‘Contact EMV Interface supported’. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results as per EMV4.3iv section 6.3.4.5. Return a Final Outcome of Try Another Interface. countries. Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.2a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. Either the card does not support Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 0b) or the card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b) and there is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities element is not present. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results as per EMV4.3iv section 6.3.4.5. 8.2.5.3a Return a Final Outcome of Try Another Interface. If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. Either the card does not support Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 0b) or the card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b) and there is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader has an alternative interface. The Card Interface and Payment Capabilities element Byte 1 Bit 6 is set to 0b, ‘Contact EMV Interface supported’. Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results as per EMV4.3iv section 6.3.4.5. The transaction continues with Terminal Risk Management. countries. Requirements – Cardholder Verification Unable To Continue over Contactless Interface 8.2.5.4a If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. Either the card does not support Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 0b) or the card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b) and there is not a mutually supported CVM across the contactless interface. The transaction is taking place in EMV mode and the reader does not have an alternative interface Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results as per EMV4.3iv section 6.3.4.5. 8.2.5.5a The transaction continues with Terminal Risk Management. If all of the following are true: The Reader CVM Required Limit Exceeded indicator is set. Either the card does not support Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 0b) or the card supports Cardholder Verification (Card AIP Byte 1 Bit 5 is set to 1b) and there is not a mutually supported CVM across the contactless interface. The transaction is taking place in mag-stripe mode Then the reader shall: Set TVR Byte 3 Bit 8 to 1b, ‘Cardholder Verification was not successful’. Set CVM Results as per EMV4.3iv section 6.3.4.5. The transaction continues with Terminal Risk Management. countries. C. 1st Card Action Analysis C.1. Changes to 11.2.1 Format of the Response to Generate AC command The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]. When CDA is not used, then the format of the response to GENERATE AC command can be in either Format 1 or Format 2 as per EMV, ICC Specifications, Version 4.3, Book 2, Section 6.6.1, step 3. As Is: Requirements – Card Action Analysis Return Formats 11.2.1.1a If CDA is not used, then: The terminal shall check that the GENERATE AC response is either in Format 1 or Format 2. 11.2.1.2a If the response is not in Format 1 or Format 2 and an alternative interface is supported by the reader and the card, then the kernel returns control to Entry Point with a Final Outcome of Try Another Interface. If CDA is used, then: The terminal shall check that the format of the GENERATE AC response is in Format 2 or Format 1 as appropriate: If either:
  • The card returns an AAC and the response is not in Format 1,
  • or the card returns an AC other than an AAC and the response is not in Format 2, 11.2.1.3a and an alternative interface is supported by the reader and the card, then the kernel returns control to Entry Point with a Final Outcome of Try Another Interface. If CDA is not used, then: The terminal shall check that the GENERATE AC response is either in Format 1 or Format. If the response is not in Format 1 or Format 2, and an alternative interface is not supported by the reader and the card, then the transaction shall be terminated. The kernel returns control to Entry Point with a Final Outcome of End Application. countries. Requirements – Card Action Analysis Return Formats 11.2.1.4a If CDA is used, then: The terminal shall check that the format of the GENERATE AC response is in Format 2 or Format 1 as appropriate: If either:
  • The card returns an AAC and the response is not in Format 1,
  • or the card returns an AC other than an AAC and the response is not in Format 2, and an alternative interface is not supported by the reader and the card, then the transaction shall be terminated. The kernel returns control to Entry Point with a Final Outcome of End Application. To Be: Requirements – Card Action Analysis Return Formats 11.2.1.1a If CDA is not used, then: The terminal shall check that the GENERATE AC response is either in Format 1 or Format 2. 11.2.1.2a If the response is not in Format 1 or Format 2 and an alternative interface is supported by the reader and the card, then the kernel returns control to Entry Point with a Final Outcome of Try Another Interface. If CDA is used, then: The terminal shall check that the format of the GENERATE AC response is in Format 2 or Format 1 as appropriate: If either:
  • The card returns an AAC and the response is not in Format 1 or Format 2,
  • or the card returns an AC other than an AAC and the response is not in Format 2, and an alternative interface is supported by the reader and the card, then the kernel returns control to Entry Point with a Final Outcome of Try Another Interface. countries. Requirements – Card Action Analysis Return Formats 11.2.1.3a If CDA is not used, then: The terminal shall check that the GENERATE AC response is either in Format 1 or Format. 11.2.1.4a If the response is not in Format 1 or Format 2, and an alternative interface is not supported by the reader and the card, then the transaction shall be terminated. The kernel returns control to Entry Point with a Final Outcome of End Application. If CDA is used, then: The terminal shall check that the format of the GENERATE AC response is in Format 2 or Format 1 as appropriate: If either:
  • The card returns an AAC and the response is not in Format 1 or Format 2,
  • or the card returns an AC other than an AAC and the response is not in Format 2, and an alternative interface is not supported by the reader and the card, then the transaction shall be terminated. The kernel returns control to Entry Point with a Final Outcome of End Application. The following amendment is applicable to [EMVC4-2.5] only: As Is: Table 11-1: Card Action analysis - Final Outcome Parameter Settings for Try Another Interface Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request N/A N/A N/A Yes Message Identifier: '18' (“Please insert/swipe card”) Status: Processing Error: Conditions for use of contactless not satisfied Hold Time: 0 Language Preference No No No Contact Chip N/A N/A countries. Removal Timeout Zero To Be: Table 11-1: Card Action analysis - Final Outcome Parameter Settings for Try Another Interface Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A N/A Yes Message Identifier: '1D' (“Please insert card”) Status: Processing Error: Conditions for use of contactless not satisfied Hold Time: 0 Language Preference No No No Contact Chip N/A N/A Zero countries. D. Online Processing D.1. Changes to 12.2.1.1 ATC Check The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]. When the ATC value retrieved in the Read Application Phase does not match the one used in the post GENERATE AC, then the transaction must be terminated, instead of declined. As Is: The reader shall validate that the post GENERATE AC ATC has the same value as the ATC retrieved in the Read Application Data transaction phase. If the two values do not match, a suspected fraudulent transaction has been attempted and the transaction must be declined. Requirements – Online Processing Mag-Stripe ATC Check 12.2.1.2a If the transaction is a mag-stripe mode transaction, then: The terminal shall compare the ATC returned by the GET DATA command to the ATC returned in the GENERATE AC command. If the ATC values do not match, then the terminal shall decline the transaction. To Be: The reader shall validate that the post GENERATE AC ATC has the same value as the ATC retrieved in the Read Application Data transaction phase. If the two values do not match, a suspected fraudulent transaction has been attempted and the transaction must be terminated. Requirements – Online Processing Mag-Stripe ATC Check 12.2.1.2a If the transaction is a mag-stripe mode transaction, then: The terminal shall compare the ATC returned by the GET DATA command to the ATC returned in the GENERATE AC command. If the ATC values do not match, then the terminal shall terminate the transaction. countries. E. Transaction Completion E.1. Changes to 13.2 Transaction Approved The following amendments are applicable to [EMVC4-2.5] and [EMVC4-2.6]. This change clarifies the user message to be displayed in the case that an approved transaction requires a cardholder signature. As Is: If the transaction is approved then the kernel returns control to Entry Point, passing a Final Outcome of Approved with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A As determined in section 8.2, Cardholder Verification – Processing Requirements Yes Message Identifier: '03' (“Approved”) State: Card Read Successfully Hold Time: 0 Language Preference No Yes No N/A N/A N/A Zero To Be: If the transaction is approved then the kernel returns control to Entry Point, passing a Final Outcome of Approved with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A As determined in section 8.2, Cardholder Verification – Processing Requirements Yes Message Identifier: '03' (“Approved”) State: Card Read Successfully Hold Time: 0 Language Preference No Yes No N/A N/A N/A Zero countries. If an approved transaction requires a cardholder signature then the kernel returns control to Entry Point, passing a Final Outcome of Approved Please Sign with the following parameter settings: Start Online Response Data CVM UI Request on Outcome Present UI Request on Restart Present Data Record Present Discretionary Data Present Alternate Interface Preference Receipt Field Off Request Removal Timeout N/A N/A As determined in section 8.2, Cardholder Verification – Processing Requirements Yes Message Identifier: '1A' (“Approved Please Sign”) State: Card Read Successfully Hold Time: 0 Language Preference No Yes No N/A N/A N/A Zero countries.

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications

countries.