PCI Watch

Tracking changes across the Payment Card Industry

SB nº 138: Errata EMV® Book C-2, Version 2.3 (Spec Change)

v1.0 Specification Bulletins
Contactless

Specification Bulletin No. 138 March 2014 Errata EMV Book C-2, Version 2.3 This Specification Bulletin contains errata for EMV Book C-2, Version 2.3.

Effective Date

This Specification Bulletin is effective from November 2014 at which time any affected or new type approval testing will come into effect.

Applicability

This specification update bulletin applies to: EMV Contactless Specifications for Payment Systems, Book C-2, Kernel 2 Specification, Version 2.3, February 2013

Related Documents

None

Description

This Specification Bulletin lists a number of errata for EMV Book C-2, Version 2.3.

http://www.emvco.com.

Specification Change Notice 1. Language Preference Description The Language Preference data object ('5F2D') is defined in EMV Book 3 as 2-8 bytes in length. In processing step S1.7, this is copied into the Language Preference subfield of User Interface Request Data, which has a fixed length of 8 bytes. The data dictionary clarifies that the data in this subfield must be "padded with hexadecimal zeroes if length of tag '5F2D' is less than 8 bytes". This bulletin adds the same clarification to the processing step itself. Specification Change The length of the Language Preference must be a multiple of 2. Modify S1.7 as follows: If the Language Preference is returned from the Card, then copy it to 'Language Preference' in User Interface Request Data: IF [IsNotEmpty(TagOf(Language Preference))] THEN 'Language Preference' in User Interface Request Data:= Language Preference If the length of Language Preference is less than 8 bytes, then pad 'Language Preference' in User Interface Request Data with trailing hexadecimal zeroes to 8 bytes. ENDIF

http://www.emvco.com.

2. Searching in Torn Transaction Log Description During an EMV mode transaction, the Kernel checks if a torn transaction recently occurred with the card. The Kernel searches in the Torn Transaction Log using the PAN and PAN Sequence Number. This could be a problem for cards not personalized with a PAN Sequence Number. This correction modifies the searching mechanism by using the PAN Sequence Number only if it has been read from the card. Specification Change In S456.E44 check if Application PAN Sequence Number is not empty. S456.E44 FOR every Record in Torn Transaction Log { IF [IsNotEmpty(TagOf(Application PAN Sequence Number))] THEN IF [Application PAN in Record = Application PAN AND Application PAN Sequence Number in Record = Application PAN Sequence Number] THEN Store reference to Record in Torn Entry for later use GOTO S456.E47 ENDIF ELSE IF [Application PAN in Record = Application PAN AND Application PAN Sequence Number is not present in Record] THEN Store reference to Record in Torn Entry for later use GOTO S456.E47 ENDIF ENDIF } [….]

http://www.emvco.com.

3. Fraud Protection – State 13 Description As a fraud protection measure during a mag-stripe mode transaction, if a valid CVC3 is not received from the cardholder device in response to the Compute Cryptographic Checksum command, the Kernel introduces an increasing delay of 2n *300ms (where n = number of consecutive invalid card responses) before another transaction can be attempted. The delay is not currently imposed by the Kernel for cardholder devices that do not provide a CVC3, but do provide POS Cardholder Interaction Information in the command response. This bulletin introduces the delay for those transactions. This correction to State 13 applies to the processing of mag-stripe mode transactions where mobile PIN verification was not requested by the Kernel. Specification Change Change S13 as follows:

  • Remove S13.40
  • Include new symbols S13.42.1, S13.42.2, S13.44.1 and S13.44.2 http://www.emvco.com. S13 4 41 No Second tap Yes needed? 42 MSG (declined) 44 Display phone message 42.1 Wait (2Failed MS Cntr * 300) ms 44.1 Wait (2Failed MS Cntr * 300) ms 42.2 Failed MS Cntr:= Min (Failed MS Cntr+1, 5) 44.2 Failed MS Cntr:= Min (Failed MS Cntr+1, 5) 43 OUT (declined) 45 OUT (end application) Exit kernel Exit kernel http://www.emvco.com. S13.40 Failed MS Cntr:= 0 S13.42.1 Wait for (2Failed MS Cntr * 300) ms Note that Failed MS Cntr is stored in the scratch pad provided to the Kernel at instantiation. Dependent on the implementation, it may be that Failed MS Cntr does not exist the first time the Kernel is executed. In this case, Failed MS Cntr must be created and initialized to zero. S13.42.2 Failed MS Cntr:= min(Failed MS Cntr + 1, 5) S13.44.1 Wait for (2Failed MS Cntr * 300) ms Note that Failed MS Cntr is stored in the scratch pad provided to the Kernel at instantiation. Dependent on the implementation, it may be that Failed MS Cntr does not exist the first time the Kernel is executed. In this case, Failed MS Cntr must be created and initialized to zero. S13.44.2 Failed MS Cntr:= min(Failed MS Cntr + 1, 5) http://www.emvco.com. 4. Fraud Protection – State 14 Description As a fraud protection measure during a mag-stripe mode transaction, if a valid CVC3 is not received from the cardholder device in response to the Compute Cryptographic Checksum command, the Kernel introduces an increasing delay of 2n *300ms (where n = number of consecutive invalid card responses) before another transaction can be attempted. The delay is not currently imposed by the Kernel for cardholder devices that do not provide a CVC3, but do provide POS Cardholder Interaction Information in the command response. This bulletin introduces the delay for those transactions. This correction to State 14 applies to the processing of mag-stripe mode transactions where mobile PIN verification was requested by the Kernel. Specification Change Change S14 as follows:
  • Remove S14.19
  • Include new symbols S14.19.4, S14.19.5, S14.44.1 and S14.44.2 http://www.emvco.com. S14 No Yes 17 Error Indication:= CARD DATA MISSING A Invalid response 1 12 Parsing OK Yes 14 ATC and PCII present ? Yes 15 CVC3 (Track 2) present ? Yes 16 Track 1 Data present and CVC3 (Track 1) not present ? No No 13 Error Indication:= PARSING ERROR A Invalid response No 2 3 http://www.emvco.com. S14 3 No 19.2 MSG (declined) 19.1 Second tap Yes needed? 22 Display phone message 19.2.1 Wait (2Failed MS Cntr * 300) ms 22.1 Wait (2Failed MS Cntr * 300) ms 19.2.2 Failed MS Cntr:= Min (Failed MS Cntr+1, 5) 19.3 OUT (declined) 22.2 Failed MS Cntr:= Min (Failed MS Cntr+1, 5) 23 OUT (end application) Exit kernel Exit kernel http://www.emvco.com. S14.19 Failed MS Cntr:= 0 S14.19.2.1 Wait for (2Failed MS Cntr * 300) ms Note that Failed MS Cntr is stored in the scratch pad provided to the Kernel at instantiation. Dependent on the implementation, it may be that Failed MS Cntr does not exist the first time the Kernel is executed. In this case, Failed MS Cntr must be created and initialized to zero. S14.19.2.2 Failed MS Cntr:= min(Failed MS Cntr + 1, 5) S14.22.1 Wait for (2Failed MS Cntr * 300) ms Note that Failed MS Cntr is stored in the scratch pad provided to the Kernel at instantiation. Dependent on the implementation, it may be that Failed MS Cntr does not exist the first time the Kernel is executed. In this case, Failed MS Cntr must be created and initialized to zero. S14.22.2 Failed MS Cntr:= min(Failed MS Cntr + 1, 5) http://www.emvco.com. 5. User Interface – State 13 Description During a mag-stripe mode transaction, if a correctly formatted response is received from the cardholder device but the transaction cannot be completed successfully in one tap, the User Interface does not clearly indicate that card reading has been completed and that the card can be withdrawn from the field. Instead of all LEDs being progressively lit over 250ms, the LEDs are not lit at all. This bulletin corrects the Kernel behavior such that when the response is received from the card the indication is immediately given that the card reading is complete. Processing then continues and an appropriate message is displayed depending on the data in the response. This is also consistent with the processing of an EMV mode transaction. This correction to State 13 applies to the processing of mag-stripe mode transactions where mobile PIN verification was not requested by the Reader. Specification Change Change S13 in such a way that ‘CARD READ SUCCESSFULLY’ is also used for the first tap in a two tap transaction. This is done by removing S13.23, renaming it S13.12.1, changing the text in the flow diagram box to be ''MSG (card read OK)'' and inserting S13.12.1 in the flow diagram between S13.12 and S13.14.1 as follows: http://www.emvco.com. S13 1 13 Error Indication:= PARSING ERROR 12 No Parsing OK Yes 12.1 MSG (card read OK) 14.1 No ATC present? Yes 14.2 CVC3 (track 2) No present? 14.3 No No PCII present? 14.4 Error Indication:= CARD DATA No MISSING Yes 14.7 nUN' = nUN A 4 Invalid response Yes 14.5 PCII present? Yes 14.6 "Offline PIN successful" in PCII set? Yes 14.8 nUN' = (nUN + 5) modulo 10 2 http://www.emvco.com. S13 2 15 Track 1 Data present and CVC3 (Track 1) not present ? No 17 Failed MS Cntr:= 0 18 Copy CVC3(Track 2), UN, and ATC in Track 2 Data 19 Copy nUN' in Track 2 Data Yes 16 Error Indication:= CARD DATA MISSING A Invalid response 20 Track 1 Data present ? No Yes 21 Copy CVC3(Track 1), UN, and ATC in Track 1 Data 22 Copy nUN' in Track 1 Data 3 http://www.emvco.com. S13.12 IF [Parsing Result] THEN GOTO S13.12.1 ELSE GOTO S13.13 ENDIF S13.12.1 'Message Identifier' in User Interface Request Data:= CLEAR DISPLAY 'Status' in User Interface Request Data:= CARD READ SUCCESSFULLY 'Hold Time' in User Interface Request Data:= '000000' Send MSG(User Interface Request Data) signal S13.20 IF [IsNotEmpty(TagOf(Track 1 Data))] THEN GOTO S13.21 ELSE GOTO S13.24 ENDIF S13.23 'Message Identifier' in User Interface Request Data:= CLEAR DISPLAY 'Status' in User Interface Request Data:= CARD READ SUCCESSFULLY 'Hold Time' in User Interface Request Data:= '000000' Send MSG(User Interface Request Data) signal http://www.emvco.com. 6. User Interface – State 14 Description During a mag-stripe mode transaction, if a correctly formatted response is received from the cardholder device but the transaction cannot be completed successfully in one tap, the User Interface does not clearly indicate that card reading has been completed and that the card can be withdrawn from the field. Instead of all LEDs being progressively lit over 250ms, the LEDs are not lit at all. This bulletin corrects the Kernel behavior such that when the response is received from the card the indication is immediately given that the card reading is complete. Processing then continues and an appropriate message is displayed depending on the data in the response. This is also consistent with the processing of an EMV mode transaction. This correction to State 14 applies to the processing of mag-stripe mode transactions where mobile PIN verification was requested by the Reader. Specification Change Change S14 in such a way that ‘CARD READ SUCCESSFULLY’ is also used for the first tap in a two tap transaction. This is done by removing S14.31, renaming it S14.12.1, changing the text in the flow diagram box to be ''MSG (card read OK)'' and inserting S14.12.1 in the flow diagram between S14.12 and S14.14 as follows: http://www.emvco.com. S14 No Yes 17 Error Indication:= CARD DATA MISSING A Invalid response 1 12 Parsing OK Yes 12.1 MSG (card read OK) 14 ATC and PCII present ? Yes 15 CVC3 (Track 2) present ? Yes 16 Track 1 Data present and CVC3 (Track 1) not present ? No No 13 Error Indication:= PARSING ERROR A Invalid response No 2 3 http://www.emvco.com. S14 4 28 Track 1 Data No present ? Yes 29 Copy CVC3(Track 1), UN, and ATC in Track 1 Data 30 Copy nUN' in Track 1 Data 32 ‘Offline PIN No Successful’ in PCII Yes set? 33 34 OUT (online, no cvm) OUT (online, confirmation code verified) Exit kernel http://www.emvco.com. S14.12 IF [Parsing Result] THEN GOTO S14.12.1 ELSE GOTO S14.13 ENDIF S14.12.1 'Message Identifier' in User Interface Request Data:= CLEAR DISPLAY 'Status' in User Interface Request Data:= CARD READ SUCCESSFULLY 'Hold Time' in User Interface Request Data:= '000000' Send MSG(User Interface Request Data) signal S14.28 IF [IsNotEmpty(TagOf(Track 1 Data))] THEN GOTO S14.29 ELSE GOTO S14.32 ENDIF S14.31 'Message Identifier' in User Interface Request Data:= CLEAR DISPLAY 'Status' in User Interface Request Data:= CARD READ SUCCESSFULLY 'Hold Time' in User Interface Request Data:= '000000' Send MSG(User Interface Request Data) signal http://www.emvco.com. 7. User Interface – State 15 Description When Standalone Data Storage (SDS) is part of the transaction, there may be one or more PUT DATA commands sent to the card following the GENERATE AC command. When the response to the last PUT DATA command is received, on the User Interface the lights are progressively switched on to indicate the successful reading of the card and the outcome of the transaction is displayed. To align with other transaction outcomes, this bulletin changes the processing such that the lights are switched off again while keeping the message on screen. Specification Change In S15.ED10, the lights are switched on (Status = CARD READ SUCCESSFULLY) and the message describing the transaction outcome is displayed (APPROVED, ONLINE AUTH,…) The lights must then be switched off in S15.ED11 while keeping the message on screen. This must be done as follows: S15.ED11 CreateEMVDiscretionaryData () IF [IsNotEmpty(TagOf(POS Cardholder Interaction Information)) AND (POS Cardholder Interaction Information AND '00030F' ≠ '000000')] THEN SET 'UI Request on Restart Present' in Outcome Parameter Set 'Status' in User Interface Request Data:= READY TO READ 'Hold Time' in User Interface Request Data:= '000000' Send OUT(GetTLV(TagOf(Outcome Parameter Set)), GetTLV(TagOf(Data Record)), GetTLV(TagOf(Discretionary Data)), GetTLV(TagOf(User Interface Request Data))) signal ELSE 'Status' in User Interface Request Data:= NOT READY 'Hold Time' in User Interface Request Data:= '000000' Send MSG(User Interface Request Data) signal Send OUT(GetTLV(TagOf(Outcome Parameter Set)), GetTLV(TagOf(Data Record)), GetTLV(TagOf(Discretionary Data))) signal ENDIF http://www.emvco.com. 8. Processing Restrictions Description As part of Processing Restrictions, it is unclear in the specification what is meant by "Cash Transaction" (PRE.E15) and "Purchase Transaction" (PRE.E20). As a result, there is also a lack of clarity regarding the applicability of certain checks involving the Application Usage Control data object that is read from the cardholder device. This bulletin modifies Processing Restrictions by referring to specific values of Transaction Type. In addition, it aligns Processing Restrictions with EMV Book 3 by clarifying that all checks are always performed (non exclusive). Specification Change Change Procedure – Processing Restrictions as follows:
  • In PRE.E15 'Cash transaction' means cash withdrawal (Transaction Type = '01') or cash disbursement (Transaction Type = '17').
  • In PRE.E20: 'Purchase transaction' means purchase (Transaction Type = '00') or purchase with cashback (Transaction Type = '09').
  • The check in PRE.E25 on cashback amount ('amount other') should be done for all purchase transactions. http://www.emvco.com. PRE 3 E15 No Cash transaction? Yes E16 Terminal Yes Country Code = Issuer No Country Code E17 ‘Valid for domestic cash No transactions’ set in AUC? E18 ‘Valid for No international cash transactions’ set in AUC? E19 Yes Yes Set ‘Requested service not allowed for card product’ in TVR 4 http://www.emvco.com. PRE 4 E20 Purchase No transaction? Yes E21 Terminal Yes Country Code = Issuer No Country Code E22 E23 ‘Valid for ‘Valid for domestic goods’ or international goods’ ‘Valid for domestic No No or ‘Valid for international services’ set in services’ set in AUC? AUC? E24 Yes Set ‘Requested service not Yes allowed for card product’ in TVR 5 http://www.emvco.com. PRE.E15 Check if Transaction Type indicates a cash transaction (cash withdrawal or cash disbursement). IF [Transaction Type indicates cash transaction = '01' OR Transaction Type = '17'] THEN GOTO PRE.E16 ELSE GOTO PRE.E20 ENDIF PRE.E17 IF ['Valid for domestic cash transactions' in Application Usage Control is set] THEN EXIT Processing Restrictions GOTO PRE.E20 ELSE GOTO PRE.E19 ENDIF PRE.E18 IF ['Valid for international cash transactions' in Application Usage Control is set] THEN EXIT Processing Restrictions GOTO PRE.E20 ELSE GOTO PRE.E19 ENDIF PRE.E20 Check if Transaction Type indicates a purchase transaction (purchase or purchase with cashback). IF [Transaction Type indicates purchase transaction = '00' OR Transaction Type = '09'] THEN GOTO PRE.E21 ELSE GOTO PRE.E25 ENDIF PRE.E22 IF ['Valid for domestic goods' in Application Usage Control is set OR 'Valid for domestic services' in Application Usage Control is set] THEN http://www.emvco.com. EXIT Processing Restrictions GOTO PRE.E25 ELSE GOTO PRE.E24 ENDIF PRE.E23 IF ['Valid for international goods' in Application Usage Control is set OR 'Valid for international services' in Application Usage Control is set] THEN EXIT Processing Restrictions GOTO PRE.E25 ELSE GOTO PRE.E24 ENDIF http://www.emvco.com. 9. Online-only Terminals Description An online-only terminal is created through configuration of the Reader Contactless Floor Limit (set to zero) and Terminal Action Code data objects. However, this mechanism does not work correctly for zero amount transactions. This bulletin corrects the specification so that online-only behavior can be created using the Terminal Type data object. The Terminal Type data object is already part of the Kernel database and is configured according to Annex A.1 of EMV Book 4. Specification Change Check for online-only terminals in TAA. Add an online-only test as follows: http://www.emvco.com. TAA Terminal Action Analysis No E2 TAC-Denial AND TVR = '0000000000' ? E1 IAC-Denial present? Yes E4 (TAC-Denial OR Yes Yes IAC-Denial) AND TVR = '0000000000' ? No E3 AC Type:= AAC No E5 AC Type:= AAC E4.1 Online-only? Yes E4.2 No AC Type:= ARQC 1 TAA.E2 IF [(Terminal Action Code – Denial AND Terminal Verification Results) = '0000000000'] THEN GOTO TAA.E4.1 ELSE GOTO TAA.E3 ENDIF http://www.emvco.com. TAA.E4 IF [((Terminal Action Code – Denial OR Issuer Action Code – Denial) AND Terminal Verification Results) = '0000000000'] THEN GOTO TAA.E4.1 ELSE GOTO TAA.E5 ENDIF TAA.E4.1 IF [(Terminal Type = '11') OR (Terminal Type = '21') OR (Terminal Type = '14') OR (Terminal Type = '24') OR (Terminal Type = '34')] THEN GOTO TAA.E4.2 ELSE GOTO TAA.E6 ENDIF TAA.E4.2 'AC type' in AC Type:= ARQC http://www.emvco.com. 10. Account Type Description The data dictionary defines the Account Type data object as updateable only by the Kernel, i.e. it is expected to be configured as part of the Kernel database. However Account Type could be provided by the POS/terminal at every transaction, and therefore provided in the ACT signal that initiates the Kernel processing. The definition in the data dictionary must reflect this. Specification Change Correct the update conditions of Account Type in the data dictionary as follows: A.1.1 Account Type Tag: Length: Format: Update: Implementations: Description: '5F57' 1 n 2 K/ACT/DET EMV, EMV/DE Indicates the type of account selected on the Terminal, coded as specified in Annex G of [EMV Book 3]. http://www.emvco.com. 11. CVM for Mag-stripe Transactions Description Among the data required by Entry Point from the Kernel as part of the transaction outcome, a CVM must be indicated. To fulfill this requirement for mag-stripe mode transactions the Mag-stripe CVM Capability – CVM Required and Mag-stripe CVM Capability – No CVM Required data objects must be configured in the Kernel database. They are configured with an appropriate CVM option (e.g. Online PIN, Signature, or No CVM). The configured value is then returned in the transaction outcome according to the conditions of the transaction (amount above or below the Reader CVM Required Limit). For mag-stripe mode transactions that require cardholder verification the POS/terminal can use the CVM in the transaction outcome data. Alternatively, it can choose the CVM according its own existing process. This may involve, for example, the service code read from the card. This correction allows this alternative approach (where the CVM is determined by the POS/terminal) to be reflected in the Kernel configuration. Specification Change Add a new value DEFINED BY TERMINAL for Mag-stripe CVM Capability – CVM Required and Mag-stripe CVM Capability – No CVM Required. A.1.94 Mag-stripe CVM Capability – CVM Required Tag: 'DF811E' Length: 1 Format: b Update: K Implementations: Always Description: Indicates the CVM capability of the Terminal/Reader in the case of a mag-stripe mode transaction when the Amount, Authorized (Numeric) is greater than the Reader CVM Required Limit. Byte 1 Mag-stripe CVM Capability – CVM Required b8-5 CVM 0000: NO CVM 0001: OBTAIN SIGNATURE 0010: ONLINE PIN 0011: DEFINED BY TERMINAL 1111: N/A Other values: RFU b4-1 RFU http://www.emvco.com. A.1.95 Mag-stripe CVM Capability – No CVM Required Tag: 'DF812C' Length: 1 Format: b Update: K Implementations: Always Description: Indicates the CVM capability of the Terminal/Reader in the case of a mag-stripe mode transaction when the Amount, Authorized (Numeric) is less than or equal to the Reader CVM Required Limit. Byte 1 Mag-stripe CVM Capability – No CVM Required b8-5 CVM 0000: NO CVM 0001: OBTAIN SIGNATURE 0010: ONLINE PIN 0011: DEFINED BY TERMINAL 1111: N/A Other values: RFU b4-1 RFU http://www.emvco.com. 12. Terminal Risk Management Data Description Some cardholder devices need to retrieve specific terminal configuration settings at the beginning of the transaction to allow the transaction flow to be optimized according to issuer business preferences. This bulletin announces the addition of a data object to the data dictionary of the Kernel to support this business need. Terminal Risk Management Data informs the cardholder device about the availability of certain functionality, such as CVM capabilities, on the terminal. It covers functionality on both the contact and contactless interfaces of the terminal. Terminal Risk Management Data may be requested by the cardholder device via a data object list returned during transaction initiation (PDOL). Specification Change Add new data object Terminal Risk Management Data to the data dictionary. A.1.153 Terminal Risk Management Data Tag: Length: Format: Update: Implementations: Description: '9F1D' 8 b K EMV, EMV/DE Application-specific value used by the cardholder device for risk management purposes. http://www.emvco.com.