Emv2000 L2 2.0

EMVCo Type Approval - Terminal Level 2 - Test Cases
EMVCo Type Approval Terminal Level 2 Test Cases

__________________________________________________
Version 2.0 January 31, 2002
Copyright 2002 EMVCo, LLC. All rights reserved
Page 1
Legal Notice
This document summarizes EMVCos present plans for type approval testing services and policies and is subject to change by EMVCo at any time without notice to any party. Neither this document nor any other document or communication creates any binding obligations upon EMVCo or any third party regarding testing services or EMVCo approval, which obligations will exist, if at all, pursuant to separate written agreements executed by EMVCo and such third parties. In the absence of a written binding agreement pursuant to which EMVCo has agreed to perform testing services for a vendor or to permit a third party to act as a test laboratory, no vendor, test laboratory nor any other third party should detrimentally rely on this document, nor shall EMVCo be liable for any such reliance.
No vendor, test laboratory nor other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a vendor, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter issued by EMVCo. All other references to EMVCo approval are strictly and actively prohibited by EMVCo.
Under no circumstances should EMVCo type approval, when granted, be construed to imply any endorsement or warranty regarding the functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received approval and to the type approval process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All rights and remedies relating to products and services that have received EMVCo type approval are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo accepts no liability whatsoever in connection with such products and services. Unless otherwise agreed in writing by EMVCo, this document and matter contained herein, including all products and services contemplated by this document are provided on an as-is basis, with all faults and with no warranties whatsoever, and EMVCo specifically disclaims any implied warranties of merchantability, fitness for purpose, or noninfringement.
Page 2
Version History
Version 1.0 2.0
Date August 31, 2000 January 31, 2002
Revision Description Initial Publication Test conformance with EMV2000 ICC Specification for Payment Systems Version 4.0 dated December, 2000.
Page 3
Table of Content
SCOPE ......................................................................................................................................................... 20 REFERENCED DOCUMENTS................................................................................................................. 21 ABBREVIATIONS AND NOTATIONS ................................................................................................... 22 GLOBAL GLOSSARY............................................................................................................................... 24 COMMAND SYNTAX ............................................................................................................................... 35 2CS.001.00 2CS.002.00 2CS.003.00 2CS.004.00 2CS.005.00 2CS.006.00 2CS.007.00 Mandatory Command Set............................................................................................... 36 Select Next Command..................................................................................................... 38 Internal Authenticate Command..................................................................................... 40 Verify Command............................................................................................................. 42 Get Challenge................................................................................................................. 44 Get Data ......................................................................................................................... 46 External Authenticate ..................................................................................................... 48
ICC SPECIFICATION FOR PAYMENT SYSTEM, TEST CASE DESCRIPTION ........................... 50 BOOK 3 PART 1 - DATA ELEMENT AND COMMANDS ...................................................................................... 50 2CA.001.03 Data elements Storage .................................................................................................. 50 2CA.001.00 Coding and Allocation of Tags ..................................................................................... 51 2CA.001.04 Coding of Length in TLV .............................................................................................. 52 2CA.002.00 Mapping of data objects into records ............................................................................ 52 2CA.004.00 Retrieval of DIR file....................................................................................................... 53 2CA.007.00 Processing Options Data Object List (PDOL)............................................................... 53 2CA.008.00 Card Risk management Data Object List 1 (CDOL1) ................................................... 54 2CA.009.00 Card Risk management Data Object List 2 (CDOL2) ................................................... 54 2CA.010.00 Transaction Data Object List (TDOL)........................................................................... 55 2CA.011.00 Dynamic Data Object List (DDOL) ............................................................................... 55 2CA.013.00 Processing DOLs: unknown tag .................................................................................... 56 2CA.014.00 Processing DOLs: constructed tag ................................................................................ 56 2CA.015.00 Processing DOLs: data absent from ICC ...................................................................... 57 2CA.016.00 Processing DOLs: shorter data object length, numeric format ..................................... 57 2CA.017.00 Processing DOLs: shorter data object length, other format.......................................... 58 2CA.018.00 Processing DOLs: longer data object length, numeric format ...................................... 59 2CA.019.00 Processing DOLs: longer data object length, compressed numeric format .................. 60 2CA.020.00 Processing DOLs: longer data object length, other format........................................... 61 2CA.021.00 Processing DOLs: data not applicable.......................................................................... 62 2CA.025.00 Normal Processing for EXTERNAL AUTHENTICATE ................................................. 63 2CA.026.00 Failed Processing for EXTERNAL AUTHENTICATE................................................... 64 2CA.027.00 Normal Processing for GENERATE AC ........................................................................ 65 2CA.028.00 Normal Processing for GET CHALLENGE................................................................... 65 2CA.029.00 Normal Processing for GET DATA ............................................................................... 66 2CA.029.05 Failed Processing for GET DATA (1)............................................................................ 67 2CA.029.06 Failed Processing for GET DATA (2)............................................................................ 68 2CA.030.00 Normal Processing for GET PROCESSING OPTIONS ................................................ 69
Page 4

2CA.030.05 2CA.031.00 2CA.032.00 2CA.032.05 2CA.033.00 2CA.034.00 2CA.034.02 2CA.034.03 2CA.034.04 2CA.035.00 2CA.036.00 2CA.037.00 2CA.039.00 2CA.040.00 2CA.041.00 2CA.054.00 2CA.055.00 2CA.056.00 2CA.057.00 2CA.058.00 2CA.059.00 2CA.060.00 2CA.061.00 2CA.062.00 2CA.063.00 2CA.064.00 2CA.065.00 2CA.066.00 2CA.067.00 2CA.070.00 2CA.071.00 2CA.072.00 2CA.074.00 2CA.075.00 2CA.076.00 2CA.077.00 2CA.078.00 2CA.081.00 2CA.082.00 2CA.083.00 2CA.084.00 2CA.088.00 2CA.089.00 2CA.092.00 2CA.093.00 2CA.094.00 2CA.095.00 2CA.096.00 2CA.097.00 2CA.098.00 2CA.099.00 2CA.103.00 2CA.104.00 2CA.108.00 Failed Processing for GET PROCESSING OPTIONS .................................................. 69 Normal Processing for Internal Authenticate................................................................ 70 Normal Processing for READ RECORD ....................................................................... 70 Failed Processing for READ RECORD......................................................................... 71 Normal Processing for Select ........................................................................................ 71 Normal Processing for VERIFY..................................................................................... 72 Failed Processing for VERIFY (1)................................................................................. 73 Failed Processing for VERIFY (2)................................................................................. 74 Failed Processing for VERIFY (3)................................................................................. 75 Status Word Processing for GENERATE AC................................................................. 76 Status Word Processing for GET CHALLENGE ........................................................... 76 Status Word Processing for GET PROCESSING OPTIONS ......................................... 77 Status Word Processing for READ RECORD................................................................ 77 Status Word Processing for VERIFY ............................................................................. 78 Coding of Bits and Bytes RFU....................................................................................... 78 Syntax of GENERATE AC returned Data Field (Format 1) ......................................... 79 Syntax of GENERATE AC returned Data Field (Format 2) ......................................... 80 Proprietary Data Object transmitted in Response to GENERATE AC: Format 2........ 80 Cryptogram Information Data...................................................................................... 81 Application Transaction Counter ................................................................................. 81 Application Cryptogram ............................................................................................... 82 Issuer Application Data ................................................................................................ 83 Cryptogram Information Data: AAC ............................................................................. 83 Cryptogram Information Data: TC................................................................................ 84 Cryptogram Information Data: ARQC .......................................................................... 84 Cryptogram Information Data: AAR ............................................................................. 85 Cryptogram Information Data: Advice required ........................................................... 85 Cryptogram Information Data: Service Not allowed..................................................... 86 Cryptogram Information Data: PIN try limit exceeded ................................................. 87 Syntax of GET DATA returned Data Field (ATC) ......................................................... 88 Syntax of GET DATA returned Data Field (LOATC) .................................................... 89 Syntax of GET DATA returned Data Field (PIN try limit) ............................................ 90 Syntax of GET PROCESSING OPTIONS Data Field (PDOL)...................................... 91 Syntax of GET PROCESSING OPTIONS Data Field (no PDOL)................................. 91 Syntax of GET PROCESSING OPTIONS Data Field: PDOL empty (implied) ............. 92 Syntax of GPO returned Data Field: Format 1 ............................................................. 93 Syntax of GPO returned Data Field: Format 2 ............................................................. 94 Syntax of INTERNAL AUTHENTICATE command ....................................................... 95 Syntax of INTERNAL AUTHENTICATE Data Field ..................................................... 95 Syntax of INTERNAL AUTHENTICATE returned Data Field: Format 1 ..................... 96 Syntax of INTERNAL AUTHENTICATE returned Data Field: Format 2 ..................... 97 Syntax of READ RECORD command ............................................................................ 98 Syntax of READ RECORD returned Data Field............................................................ 98 Syntax of SELECT Data Field ....................................................................................... 99 Syntax of SELECT PSE returned Data Field................................................................. 99 Syntax of SELECT PSE returned Data Field: optional data ....................................... 100 Syntax of SELECT DDF returned Data Field ............................................................. 101 Syntax of SELECT DDF returned Data Field: optional data (implied) ..................... 102 Syntax of SELECT ADF returned Data Field.............................................................. 103 Syntax of SELECT ADF returned Data Field: optional data ...................................... 103 Response to Proprietary Data in FCI .......................................................................... 104 Syntax of VERIFY Data Field for option plaintext offline PIN.................................... 104 Syntax of VERIFY Data Field...................................................................................... 105 Syntax of GET CHALLENGE returned Data Field ..................................................... 105
Page 5

APPLICATION SELECTION................................................................................................................. 106 2CB.002.00 2CB.004.00 2CB.005.00 2CB.006.00 2CB.007.00 2CB.010.00 2CB.011.00 2CB.012.00 2CB.013.00 Supported 2CB.014.00 2CB.016.00 2CB.017.00 2CB.018.00 2CB.019.00 2CB.020.00 2CB.021.00 2CB.022.00 2CB.023.00 2CB.024.00 2CB.024.01 2CB.025.00 2CB.025.06 2CB.026.05 2CB.028.00 2CB.029.00 2CB.031.00 2CB.031.06 2CB.031.07 2CB.032.00 2CB.034.00 2CB.035.00 2CB.036.00 2CB.037.00 2CB.038.00 2CB.039.00 2CB.040.00 2CB.041.00 2CB.042.00 2CB.049.00 2CB.050.00 required 2CB.053.00 2CB.054.00 2CB.055.00 2CC.003.00 2CC.004.00 2CC.006.00 2CC.007.00 Definition of PSE ......................................................................................................... 106 Definition of a Record in Payment Systems Directory................................................. 107 Definition of Directory Entry Format .......................................................................... 108 Reading the Directory.................................................................................................. 109 Terminals List of Supported Applications .................................................................. 109 Matching AIDS: same AID criteria supported....................................................... 110 Matching AIDs: AID beginning with Terminal AID criteria supported ................ 111 Selection Using the Payment Systems Directory: SELECT PSE.................................. 112 Selection Using the Payment Systems Directory: Card Blocked or Command Not 112 Selection Using the Payment Systems Directory: SELECT PSE returns an error....... 113 Indicating end of record .............................................................................................. 113 Directory empty or not present .................................................................................... 114 Directory entry processing........................................................................................... 114 Candidate list............................................................................................................... 115 Candidate list (implied) ............................................................................................... 115 DDF entry .................................................................................................................... 116 DDF entry failed .......................................................................................................... 117 Candidate List empty after selection with PSE ............................................................ 118 Selection using a list of AIDs ....................................................................................... 118 Selection using a list of AIDs: SELECT command ...................................................... 119 Selection using a list of AIDs: SELECT fails ............................................................... 119 DF name and AID identical & SELECT command successful..................................... 120 DF name and AID identical & application blocked .................................................... 121 Selection using a list of AIDs ....................................................................................... 122 Selection using a list of AIDs: candidate list completion............................................. 123 Application Selection Indicator: One Occurrence Permitted ...................................... 124 DF name longer than AID & multiple occurrence & application not blocked ............ 125 DF name longer than AID & multiple occurrence & application blocked .................. 126 DFNAME is different from AID ................................................................................... 127 Multiple occurrence of application: next option supported: 90 00 ............................. 128 Multiple occurrence of application: next option failed: 62 83 .................................... 129 Multiple occurrence of application: next option failed: other..................................... 130 Final Selection: no mutually supported application.................................................... 130 Final Selection: one mutually supported application .................................................. 131 Final Selection: cardholder confirmation.................................................................... 131 Final Selection: no cardholder confirmation............................................................... 132 Final Selection: cardholder does not approve............................................................. 132 Displaying Application to Cardholder: priority sequence........................................... 133 Terminal Selection of Application without Cardholder Assistance ............................. 134 Terminal Selection of Application without Cardholder Assistance: confirmation 135 Final Selection of Application from Candidate List: list of AID.................................. 136 Final Selection of Application from Candidate List: PSE ........................................... 137 Final Selection of Application from Candidate List: SELECT status different from 90 00138 Terminal shall be able to store 6 CA Index per RID.................................................... 139 Algorithm For SDA ...................................................................................................... 140 Bit Length of all Moduli............................................................................................... 141 Value of Certification Authority Public Key Exponent ................................................ 142
SECURITY ASPECTS ............................................................................................................................. 139
Page 6

2CC.008.00 2CC.009.00 2CC.010.00 2CC.011.00 2CC.012.00 2CC.014.00 2CC.015.00 2CC.017.00 2CC.018.00 2CC.019.00 2CC.020.00 2CC.021.00 2CC.022.00 2CC.023.00 2CC.024.00 2CC.026.00 2CC.028.00 2CC.029.00 2CC.030.00 2CC.031.00 2CC.032.00 2CC.033.00 2CC.036.00 2CC.037.00 2CC.039.00 2CC.040.00 2CC.041.00 2CC.042.00 2CC.043.00 2CC.044.00 2CC.045.00 2CC.046.00 2CC.047.00 2CC.049.00 2CC.050.00 2CC.052.00 2CC.053.00 2CC.054.00 2CC.055.00 2CC.056.00 2CC.057.00 2CC.058.00 2CC.059.00 2CC.061.00 2CC.063.00 2CC.064.00 2CC.065.00 2CC.066.00 2CC.067.00 2CC.068.00 2CC.069.00 2CC.071.00 2CC.072.00 2CC.074.00 2CC.075.00 Value of Issuer Public Key Exponent........................................................................... 143 Data missing: CA Public Key Index............................................................................. 144 Data missing: Issuer PK Certificate ............................................................................ 145 Data missing: Issuer PK Exponent .............................................................................. 146 Data missing: Signed Static Application data ............................................................. 147 Retrieving CA Public Key used to Perform SDA: Key absent...................................... 148 Length of Issuer Public Key Certificate ....................................................................... 149 Recovered Data Trailer not equal to BC................................................................... 150 Recovered Data Header not equal to 6A................................................................... 151 Certificate Format not equal to 02............................................................................ 152 Difference between calculated Hash Result and recovered Hash Result..................... 153 IIN does not match leftmost 3-8 PAN digits................................................................. 154 Certificate Expiration Date earlier than todays date ................................................. 155 RID, CA Public Key Index and Certificate Serial Number not valid ........................... 156 Issuer Public Key Algorithm not recognized................................................................ 157 Signed Static Application Data Length not OK ........................................................... 158 Recover Data Trailer not equal to BC ...................................................................... 159 Recover Data Header not equal to 6A ...................................................................... 160 Certificate Format not equal to 03............................................................................ 161 Difference between calculated Hash Result and recovered Hash Result..................... 162 SDA Tag List in Static Data Authentication ................................................................ 163 Data Authentication Code Stored ................................................................................ 164 Terminal shall be able to store 6 CA Index per RID.................................................... 165 Algorithm for DDA ...................................................................................................... 166 Bit Length of All Moduli .............................................................................................. 167 Value of CA Public Key Exponent ............................................................................... 168 Value of Issuer Public Key Exponent........................................................................... 169 Value of ICC Public Key Exponent.............................................................................. 170 Data missing: CA Public Key Index............................................................................. 171 Data missing: Issuer Public Key Certificate................................................................ 172 Data missing: Issuer PK Exponent .............................................................................. 173 Data missing: ICC Public Key Certificate ................................................................... 174 Data missing: ICC Public Key Exponent..................................................................... 175 Retrieving CA Public Key used to Perform DDA: Key absent..................................... 176 Length of Issuer Public Key Certificate ....................................................................... 177 Recover Data Trailer not equal to BC ...................................................................... 178 Recover Data Header not equal to 6A ...................................................................... 179 Certificate Format not equal to 02............................................................................ 180 Difference between calculated Hash Result and recovered Hash Result..................... 181 IIN does not match leftmost 3-8 PAN digits................................................................. 182 Certificate Expiration Date earlier than todays date ................................................. 183 RID, CA Public Key Index and Certificate Serial Number not valid ........................... 184 Issuer Public Key Algorithm not recognized................................................................ 185 Length of ICC Public Key Certificate .......................................................................... 186 Recover Data Trailer not equal to BC ...................................................................... 187 Recover Data Header not equal to 6A ...................................................................... 188 Certificate Format not equal to 04............................................................................ 189 Difference between calculated Hash Result and recovered Hash Result..................... 190 Recovered PAN is not equal to read PAN.................................................................... 191 Certificate Expiration Date earlier than todays date ................................................. 192 ICC Public Key Algorithm not recognized................................................................... 193 Dynamic Signature generation .................................................................................... 194 Default DDOL.............................................................................................................. 195 Source of Unpredictable Number ................................................................................ 196 DDOL does not contain unpredictable Number .......................................................... 197
Page 7

2CC.076.00 2CC.078.00 2CC.079.00 2CC.080.00 2CC.081.00 2CC.082.00 2CC.083.00 2CC.084.00 2CC.085.00 2CC.086.00 2CC.091.00 2CC.094.00 2CC.095.00 2CC.096.00 2CC.097.00 2CC.098.00 2CC.099.00 2CC.100.00 2CC.101.00 2CC.102.00 2CC.119.00 2CC.120.00 2CC.121.00 2CC.122.00 2CC.122.01 2CC.123.00 2CC.124.00 2CC.125.00 2CC.126.00 2CC.127.00 2CC.127.01 2CC.128.00 2CC.129.00 2CC.130.00 2CC.131.00 2CC.132.00 2CC.133.00 2CC.135.00 2CC.136.00 2CC.137.00 2CE.001.00 2CE.001.01 2CE.001.02 2CG.002.00 2CH.001.00 2CH.002.00 2CH.003.00 Default DDOL does not contain unpredictable Number ............................................. 198 Signed Dynamic Application Data Length not OK ...................................................... 199 Recovery Function ....................................................................................................... 200 Recover Data Trailer not equal to BC ...................................................................... 201 Recover Data Header not equal to 6A ...................................................................... 202 Certificate Format not equal to 05............................................................................ 203 Difference between calculated Hash Result and recovered Hash Result..................... 204 Dynamic Data Authentication is OK............................................................................ 205 SDA Tag List in Dynamic Data Authentication ........................................................... 206 ICC Dynamic Number Stored ...................................................................................... 207 Key used for PIN Encryption/Decryption .................................................................... 208 Random behaviour of PIN Encipherment padding pattern.......................................... 209 Value of ICC PIN Encryption Public Key Exponent.................................................... 210 ICC PIN Encipherment Public Key recovering: ICC PIN Encipherment Public Key . 211 ICC PIN Encipherment Public Key recovery: ICC Issuer Public Key......................... 212 ICC PIN Encipherment Public Key recovering failed ................................................. 213 PIN Entry ..................................................................................................................... 214 Unpredictable Number................................................................................................. 215 Enciphered PIN Data................................................................................................... 215 VERIFY ........................................................................................................................ 216 PDOL in Enhanced Combined DDA/AC ..................................................................... 217 Unpredictable Number (Tag 9F 37) in CDOL1........................................................... 218 Unpredictable number (Tag 9F 37) in CDOL2 ........................................................... 219 ICC responds with AAC (1).......................................................................................... 220 ICC responds with AAC (2).......................................................................................... 221 Signed Dynamic Application Data Length................................................................... 222 Recovered Data trailer not equal to BC ...................................................................... 223 Recovered Data header not equal to 6A ...................................................................... 224 Recovered Signed Data Format not equal to 05.......................................................... 225 Recovered CID different from CID obtained after Generate AC (1) ........................... 226 Recovered CID different from CID obtained after Generate AC (2) ........................... 227 Compare hash result .................................................................................................... 228 Compare Transaction Data Hash Code....................................................................... 229 Issuer Application Data in Enhanced Combined DDA/AC ......................................... 230 ICC Dynamic Number is stored ................................................................................... 231 Application Cryptogram stored ................................................................................... 232 Unpredictable Number generated by the terminal....................................................... 233 Signed Dynamic Application Data is not present in response to generate AC ............ 234 Values of CDOL1 for Transaction Data hash.............................................................. 235 Values of PDOL for Transaction Data hash................................................................ 236 Length field: 1 byte ...................................................................................................... 237 Length field: 2 bytes ..................................................................................................... 237 Length field: 3 bytes ..................................................................................................... 238 Signature verification .................................................................................................. 239 The Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys......... 240 Coding the Public Key Algorithm Indicator ................................................................ 241 Upper bound for size of moduli ................................................................................... 242
DATA OBJECTS ...................................................................................................................................... 237
SECURITY MECHANISMS ................................................................................................................... 239 APPROVED CRYPTOGRAPHIC ALGORITHMS ............................................................................. 240
Page 8

2CH.010.00 Coding of Hash Algorithm Indicator ........................................................................... 243
ICC APPLICATION SPECIFICATION FOR PAYMENT SYSTEM, TEST CASE DESCRIPTION244 FILES FOR FINANCIAL TRANSACTION INTERCHANGE .................................................................................... 244 2CI.001.00 READ RECORD with the Short File Identifiers (SFI) ranged from 1 to 10 ................. 244 2CI.002.00 READ RECORD in linear files ..................................................................................... 245 2CI.003.00 READ RECORD in files containing multiple records .................................................. 245 2CI.004.00 READ RECORD with the record size in the range from 1 to 254 bytes ....................... 246 2CI.005.00 Record Data Format..................................................................................................... 246 2CI.007.00 Free access conditions for files accessible using the READ RECORD command ....... 247 2CI.008.00 READ RECORD in the Application File Locator......................................................... 247 2CI.009.00 Mandatory Data Objects: Application Expiration Date............................................... 248 2CI.010.00 Mandatory Data Objects: PAN .................................................................................... 248 2CI.011.00 Mandatory Data Objects: CDOL 1 .............................................................................. 249 2CI.012.00 Mandatory Data Objects: CDOL 2 .............................................................................. 249 2CI.013.00 Optional Data Objects: ................................................................................................ 250 2CI.014.00 Mandatory Data Objects for Offline Static Data Authentication ................................. 251 2CI.015.00 Mandatory Data Objects for Offline Dynamic Data Authentication............................ 252 2CI.017.00 GET DATA on PIN Try Counter................................................................................... 253 2CI.018.00 GET DATA on Last Online ATC Register .................................................................... 253 2CI.019.00 Both the LCOL and UCOL data objects exist in the ICC ............................................. 254 2CI.020.00 Either the LCOL or the UCOL data objects is not present in the ICC ......................... 255 2CI.021.00 Data retrievable by GET PROCESSING OPTIONS command .................................... 256 2CI.022.00 Functions specified in the AIP: Offline Static Data Authentication ............................. 257 2CI.023.00 Functions not specified in the AIP: Offline Static Data Authentication ....................... 258 2CI.024.00 Functions specified in the AIP: Offline Dynamic Data Authentication........................ 259 2CI.025.00 Functions not specified in the AIP: Offline Dynamic Data Authentication.................. 260 2CI.026.00 Functions specified in the AIP: Cardholder verification.............................................. 261 2CI.027.00 Functions not specified in the AIP: Cardholder verification........................................ 262 2CI.028.00 Functions specified in the AIP: Terminal Risk Management ....................................... 263 2CI.029.00 Functions not specified in the AIP: Terminal Risk Management ................................. 264 2CI.030.00 Functions specified in the AIP: Issuer Authentication ................................................. 265 2CI.031.00 Functions not specified in the AIP: Issuer Authentication ........................................... 266 2CI.032.00 Exception Handling ...................................................................................................... 267 2CI.033.00 Functions specified in the Application Interchange Profile: Enhanced Combined DDA / GENERATE AC268 2CI.034.00 Functions not specified in the Application Interchange Profile: Enhanced Combined DDA / GENERATE AC ........................................................................................................................... 269 FUNCTIONS USED IN TRANSACTION PROCESSING ......................................................................................... 270 2CJ.001.00 GET PROCESSING OPTIONS command execution.................................................... 270 2CJ.002.00 All bits in TSI and TVR are set to 0b ............................................................................ 270 2CJ.003.00 GET PROCESSING OPTIONS data field, when PDOL is provided in FCI ................ 271 2CJ.004.00 GET PROCESSING OPTIONS data field, when PDOL is not provided in FCI .......... 271 2CJ.005.00 Rules for Processing Tags listed in the PDOL (1)........................................................ 272 2CJ.006.00 Rules for Processing Tags listed in the PDOL (2)........................................................ 273 2CJ.007.00 Rules for Processing Tags listed in the PDOL (3)........................................................ 274 2CJ.008.00 GET PROCESSING OPTIONS transaction state management.................................... 275 2CJ.009.00 READ RECORD command execution .......................................................................... 275 2CJ.010.00 READ RECORD on each entry in the AFL .................................................................. 276 2CJ.011.00 Data objects processing................................................................................................ 276 2CJ.012.00 Data objects processing (Unrecognized Data Objects)................................................ 277 2CJ.012.01 Non recognized data object participating in offline data authentication ..................... 278 2CJ.013.00 Record Data Format: mandatory data: Application Expiration Date ......................... 279 2CJ.014.00 Record Data Format: mandatory data: PAN ............................................................... 279 2CJ.015.00 Record Data Format: mandatory data: CDOL1 .......................................................... 280
Page 9

2CJ.016.00 Record Data Format: mandatory data: CDOL2 .......................................................... 280 2CJ.017.00 Record Data Format: Unique data objects .................................................................. 281 2CJ.018.00 Record Data Format: Proprietary data participating in offline data authentication .. 281 2CJ.020.00 Offline Data Authentication is supported ..................................................................... 282 2CJ.021.00 Both the Terminal and the Card support Enhanced Combined DDA/AC (TC, 1st Generate AC) 283 2CJ.021.01 Both the Terminal and the Card support Enhanced Combined DDA/AC (TC, 2nd Generate AC) 284 2CJ.021.02 Both the Terminal and the Card support Enhanced Combined DDA/AC (ARQC) ...... 285 2CJ.022.00 Both the Terminal and the Card support Offline SDA.................................................. 286 2CJ.023.00 Both the Offline DDA and the Offline SDA are supported ........................................... 287 2CJ.024.00 Neither the Offline DDA nor the Offline SDA nor the Enhanced Combined DDA/AC is performed 288 2CJ.025.00 Rules for Processing the Input Data............................................................................. 289 2CJ.026.00 Rules for Processing the records identified by the AFL, when the Offline DDA is performed (1) 290 2CJ.027.00 Rules for Processing the records identified by the AFL, when the Offline DDA is performed (2) 291 2CJ.028.00 Rules for Processing the records identified by the AFL, when the Offline SDA is performed (1) 292 2CJ.029.00 Rules for Processing the records identified by the AFL, when the Offline SDA is performed (2) 293 2CJ.032.00 Offline Static Data Authentication fails........................................................................ 294 2CJ.033.00 Offline Dynamic Data Authentication fails .................................................................. 295 2CJ.033.05 Enhanced Combined DDA/AC fails.............................................................................. 296 2CJ.034.00 Set relevant bit in TSI, upon completion of the Offline Data Authentication ............... 297 2CJ.035.00 Processing Restrictions function execution .................................................................. 298 2CJ.036.00 Application Version Number assigned by the payment system .................................... 299 2CJ.037.00 Application Version Number is not present in the ICC................................................ 300 2CJ.039.00 Application Version Number present in the ICC and in the terminal are the same (implied) 301 2CJ.041.00 AUC is present in the ICC and Transaction is conducted at an ATM ......................... 302 2CJ.042.00 AUC is present in the ICC and Transaction is conducted at an ATM (implied) .......... 303 2CJ.043.00 AUC is present in the ICC and Transaction is not conducted at an ATM ................... 304 2CJ.044.00 AUC is present in the ICC and Transaction is not conducted at an ATM (implied).... 305 2CJ.045.00 Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code 306 2CJ.046.00 Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code (implied) 307 2CJ.047.00 Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code 308 2CJ.048.00 Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code (implied) .......................................................................................................................... 309 2CJ.049.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code 310 2CJ.050.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code (implied) 311 2CJ.051.00 Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code .......................................................................................................................... 312 2CJ.052.00 Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code (implied)........................................................................................................... 313 2CJ.053.00 Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code 314
Page 10

2CJ.054.00 Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code (implied) .......................................................................................................................... 315 2CJ.055.00 Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code .......................................................................................................................... 316 2CJ.056.00 Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code (implied)........................................................................................................... 317 2CJ.057.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code 318 2CJ.058.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code (implied) 319 2CJ.059.00 Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code 320 2CJ.060.00 Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code (implied) .......................................................................................................................... 321 2CJ.061.00 Application Usage Control is not present in the ICC (implied) ................................... 322 2CJ.062.00 Application Usage Control is present in the ICC but not Issuer Country code (implied)323 2CJ.063.00 Current Date is less than Application Effective Date .................................................. 324 2CJ.064.00 Current Date is greater than Application Effective Date (implied) ............................. 325 2CJ.064.01 Current Date is equal to Application Effective Date (implied) .................................... 326 2CJ.065.00 Current Date is greater than Application Expiration Date ......................................... 327 2CJ.066.00 Current Date is less than Application Expiration Date (implied)................................ 327 2CJ.066.01 Current Date is equal to the Application Expiration Date (implied) ........................... 328 2CJ.067.00 Application Effective Date is not present in the ICC (implied).................................... 329 2CJ.068.00 Cardholder Verification is supported in the AIP.......................................................... 330 2CJ.069.00 Supported CVR condition: Always ............................................................................... 330 2CJ.070.00 Supported CVR condition: If Cash or Cashback.......................................................... 331 2CJ.071.00 Supported CVR condition: If not Cash or Cashback.................................................... 332 2CJ.073.00 Supported CVR condition: If Terminal supports the CVM and CVM is offline PIN .... 333 2CJ.074.00 Supported CVR condition: If Terminal supports the CVM and CVM is online PIN..... 334 2CJ.075.00 Supported CVR condition: If Terminal supports the CVM and CVM is signature....... 335 2CJ.077.00 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is less than X .................................................................................. 336 2CJ.077.01 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is greater than X ............................................................................ 337 2CJ.077.02 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is equal to X ................................................................................... 338 2CJ.078.00 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is greater than X. ................................................................................. 339 2CJ.078.01 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is less than X. ....................................................................................... 340 2CJ.078.02 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is equal to X. ........................................................................................ 341 2CJ.079.00 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is less than Y. ................................................................................. 342 2CJ.079.01 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is greater than Y............................................................................. 343 2CJ.079.02 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is equal to Y. .................................................................................. 344 2CJ.080.00 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is greater than Y............................................................................. 345 2CJ.080.01 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is equal to Y. .................................................................................. 346 2CJ.080.02 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is less than Y. ................................................................................. 347
Page 11

2CJ.081.01 Random Transaction Selection: Transaction Amount Less than the Threshold Value for Biased Random Selection ....................................................................................................................... 348 2CJ.081.02 Random Transaction Selection: Transaction Amount Less than the Threshold Value for Biased Random Selection ....................................................................................................................... 349 2CJ.081.03 Random Transaction Selection: Transaction Amount Equal to or Greater than the Threshold Value for Biased Random Selection but Less than the Floor Limit ....................................... 350 2CJ.081.04 Random Transaction Selection: Transaction Amount Equal to or Greater than the Threshold Value for Biased Random Selection but Less than the Floor Limit ....................................... 351 2CJ.082.01 CVM List is not present in the ICC............................................................................... 352 2CJ.082.02 CVM List is present in the ICC..................................................................................... 352 2CJ.083.00 Second byte of a Cardholder Verification Rule is not satisfied .................................... 353 2CJ.083.01 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Plaintext PIN 354 2CJ.083.02 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Enciphered PIN 355 2CJ.083.03 Non Supported CVR condition: If Terminal supports the CVM and CVM is online Enciphered PIN 356 2CJ.083.04 Non Supported CVR condition: If Terminal supports the CVM and CVM is Signature357 2CJ.083.05 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Plaintext PIN and Signature................................................................................................................... 358 2CJ.083.06 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Enciphered PIN and Signature............................................................................................................... 359 2CJ.083.07 No Supported CVR condition: If Terminal supports the CVM and CVM is No CVM Required 360 2CJ.084.00 ICC Data required by the CVM Condition Code is missing......................................... 361 2CJ.085.00 CVM Condition Code is outside the range of codes understood by the terminal ......... 362 2CJ.086.00 Cardholder Verification is not successful..................................................................... 363 2CJ.087.00 Second byte of Cardholder Verification Rule satisfied and CVM Code is Fail CVM .. 364 2CJ.088.00 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC (Plain text PIN verified by ICC supported) ...................................................................................................... 365 2CJ.088.01 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC (Plain text PIN verified by ICC not supported) ................................................................................................ 366 2CJ.089.00 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online supported)............................................................................................................................ 367 2CJ.089.01 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online not supported)...................................................................................................................... 368 2CJ.090.00 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC and signature (Plain text PIN verified by ICC and signature supported) ..................................................... 369 2CJ.090.01 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC and signature (Plain text PIN verified by ICC and signature not supported) ............................................... 370 2CJ.091.00 Second byte of CVR satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC supported) ......................................................................................... 371 2CJ.091.01 Second byte of CVR satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC not supported) ................................................................................... 372 2CJ.092.00 Second byte of CVR satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature supported) .................................................. 373 2CJ.092.01 Second byte of CVR satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature not supported) ............................................ 374 2CJ.093.00 Second byte of CVR satisfied and CVM Code is signature (signature supported) ....... 375 2CJ.093.01 Second byte of CVR satisfied and CVM Code is signature (signature not supported) . 376 2CJ.094.00 Second byte of CVR satisfied and CVM Code is no CVM required (No CVM required is supported) 377
Page 12

2CJ.094.01 Second byte of CVR satisfied and CVM Code is No CVM required (No CVM required is not supported) 378 2CJ.095.00 Second byte of CVR satisfied and CVM Code not understood by the terminal ............ 379 2CJ.096.00 CVM processing succeeds ............................................................................................ 380 2CJ.097.00 CVM processing fails and CVR indicates to proceed with next rule ............................ 381 2CJ.098.00 CVM processing fails and no more CVR in the CVM List............................................ 382 2CJ.099.00 CVM processing fails and CVR indicates to not proceed with next rule ...................... 383 2CJ.100.00 Cardholder Verification is completed .......................................................................... 384 2CJ.102.00 Offline PIN verification returns 63 Cx ......................................................................... 385 2CJ.103.00 Offline PIN is the selected CVM and Terminal does not support offline PIN .............. 386 2CJ.104.00 Offline PIN is the selected CVM, Terminal supports offline PIN, and the PIN pad is malfunctioning 387 2CJ.106.00 Offline PIN is the selected CVM and PIN is blocked.................................................... 388 2CJ.107.00 Offline PIN is the selected CVM and the number of remaining PIN trials is zero ....... 389 2CJ.108.00 Offline PIN is the selected CVM and the offline PIN processing is successful............. 390 2CJ.109.00 Online PIN is the selected CVM and Terminal does not support online PIN............... 391 2CJ.110.00 Online PIN is the selected CVM, Terminal supports online PIN, and the PIN pad is malfunctioning 392 2CJ.112.00 Online PIN is the selected CVM and the online PIN processing is successful ............. 393 2CJ.113.00 Signature (paper) is a required CVM and Terminal supports the signature process... 394 2CJ.114.00 Combination CVM: success.......................................................................................... 395 2CJ.115.00 Combination CVM: failure........................................................................................... 396 2CJ.116.00 Terminal Risk Management is supported in AIP .......................................................... 397 2CJ.118.00 Terminal Risk Management is not supported in AIP.................................................... 398 2CJ.119.00 Transaction log entry with the same PAN is available and Terminal Floor Limit is exceeded 399 2CJ.120.00 Transaction log entry with the same PAN is available and Terminal Floor Limit is not exceeded (implied) .................................................................................................................................. 400 2CJ.123.00 Transaction log is not available and Terminal Floor Limit is exceeded ...................... 401 2CJ.124.00 Transaction log is not available and Terminal Floor Limit is not exceeded (implied) 402 2CJ.127.00 Transaction log entry with the same PAN is not available and Terminal Floor Limit is exceeded 403 2CJ.128.00 Transaction log entry with the same PAN is not available and Terminal Floor Limit is not exceeded (implied) ............................................................................................................................ 404 2CJ.137.00 Both the Lower and the Upper Consecutive Offline Limit are present in the ICC ....... 405 2CJ.138.00 Either the Lower or the Upper Consecutive Offline Limit is not present in the ICC.... 406 2CJ.139.00 GET DATA on both the ATC and the Last Online ATC Register ................................. 407 2CJ.140.00 The ATC Register is not present in the ICC.................................................................. 408 2CJ.140.01 The Last Online ATC Register is not present in the ICC .............................................. 409 2CJ.141.00 (ATC - Last Online ATC Register) > Lower Consecutive Offline Limit ....................... 410 2CJ.142.00 (ATC - Last Online ATC Register) = Lower Consecutive Offline Limit (implied)........ 411 2CJ.143.00 (ATC - Last Online ATC Register) < Lower Consecutive Offline Limit (implied)........ 412 2CJ.144.00 (ATC - Last Online ATC Register) > Upper Consecutive Offline Limit ....................... 413 2CJ.145.00 (ATC - Last Online ATC Register) = Upper Consecutive Offline Limit (implied)........ 414 2CJ.146.00 (ATC - Last Online ATC Register) < Upper Consecutive Offline Limit (implied)............... 415 2CJ.147.00 Last Online ATC Register = 0 ...................................................................................... 416 2CJ.148.00 Terminal Risk Management completion ....................................................................... 417 2CJ.149.00 Terminal Action Analysis function execution ............................................................... 418 TERMINAL ACTION CODE (TAC) ................................................................................................................. 419 2CJ.150.00 TAC Denial processing bit set to 1b ............................................................................. 419 2CJ.151.00 TAC Denial processing bit set to 0b ............................................................................. 420 2CJ.152.00 TAC Online Processing, bit set to 1b............................................................................ 421 2CJ.153.00 TAC Online Processing, bit set to 0b............................................................................ 422 2CJ.154.00 TAC Default processing bit set to 1b, & terminal unable to go online......................... 423 2CJ.155.00 TAC Default processing bit set to 0b, & terminal unable to go online......................... 424
Page 13

2CJ.156.00 TAC Default processing bit set to 1b, & terminal has no online capability ................. 425 2CJ.157.00 TAC Default processing bit set to 0b, & terminal has no online capability ................. 426 ISSUER ACTION CODE (IAC)........................................................................................................................ 427 2CJ.158.00 TVR and Issuer Action Code-Denial check requests an AAC...................................... 427 2CJ.159.00 TVR and IAC-Denial check requests a TC (implied)................................................... 428 2CJ.160.00 Terminal has online capability, TVR and Issuer Action Code-Online check requests an ARQC 429 2CJ.161.00 Terminal has online capability, TVR and Online Action Codes check requests a TC (implied) 430 2CJ.162.00 Terminal is unable to go online, TVR and Issuer Action Code-Default check requests an AAC 431 2CJ.163.00 Terminal is unable to go online, TVR and Default Action Codes check requests a TC432 2CJ.164.00 Terminal has not online capability, TVR and Issuer Action Code-Default check requests an AAC 433 2CJ.165.00 Terminal has not online capability, TVR and Default Action Codes check requests a TC434 TERMINAL AND ISSUER ACTION ANALYSIS .................................................................................................. 435 2CJ.166.00 IAC-Denial is not present in the ICC ........................................................................... 435 2CJ.167.00 IAC-Online is not present in the ICC ........................................................................... 436 2CJ.168.00 IAC-Default is not present in the ICC and the Terminal is unable to go online .......... 437 2CJ.169.00 IAC-Default is not present in the ICC and the Terminal is offline only ....................... 438 2CJ.169.02 IAC-Default is not present in the ICC and the Terminal is offline only (2).................. 439 2CJ.169.05 Tag for Terminal Capability Profile not include in ICC's CDOL1 .............................. 440 2CJ.170.00 Card Action Analysis function completion ................................................................... 440 2CJ.175.00 Generate AC Response in a Public Key Envelope........................................................ 441 2CJ.177.00 Advice messages during Card Action Analysis............................................................. 441 2CJ.178.00 Online Processing function execution .......................................................................... 442 2CJ.180.00 IAD is received from the Issuer and Issuer Authentication is supported in AIP .......... 443 2CJ.181.00 EXTERNAL AUTHENTICATE unsuccessful ................................................................ 444 2CJ.182.00 IAD is received from the Issuer and Issuer Authentication is not supported in AIP .... 445 2CJ.183.00 IAD is not received from the Issuer .............................................................................. 446 2CJ.185.00 EXTERNAL AUTHENTICATE performed.................................................................... 447 2CJ.186.00 Multiple Issuer Scripts may be provided with a single authorization response ........... 448 2CJ.187.00 Issuer Script may contain several Issuer Script Commands......................................... 449 2CJ.188.00 Issuer Script Command unknown to the terminal......................................................... 450 2CJ.189.00 Issuer Script with Tag 71 execution........................................................................... 451 2CJ.190.00 Issuer Script with Tag 72 execution........................................................................... 451 2CJ.191.00 Issuer Script Format..................................................................................................... 452 2CJ.192.00 Script Identifier in Issuer Script ................................................................................... 453 2CJ.193.00 Issuer Script processing................................................................................................ 453 2CJ.194.00 Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 71............. 454 2CJ.195.00 Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 72............. 455 2CJ.196.00 Issuer Script Commands delivery to ICC ..................................................................... 456 2CJ.197.00 SWI in the Status Code equals 90, 62, or 63 ........................................................ 457 2CJ.198.00 SWI in the Status Code equals 90 or 62, or 63 (implied)....................................... 458 2CJ.199.00 SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 71459 2CJ.200.00 SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 72460 2CJ.201.00 Issuer Script processed ................................................................................................. 461 2CJ.202.00 Issuer Script not processed (implied) ........................................................................... 462 2CJ.203.00 Enhanced Combined DDA/AC failed when ICC responded with TC (1)...................... 463 2CJ.203.01 Enhanced Combined DDA/AC failed when ICC responded with TC (2)...................... 464 GENERATE AC COMMAND CODING ......................................................................................................... 465 2CK.001.00 CDOL1 for the first GENERATE AC........................................................................... 465 2CK.002.00 CDOL2 for the second GENERATE AC ...................................................................... 465
Page 14

CDOL requests a TC Hash Value and TDOL is present in the ICC ............................ 466 CDOL requests a TC Hash Value and TDOL is not present in the ICC...................... 467 CDOL requests a TC Hash Value and neither TDOL nor default TDOL is present.... 468 CDOL requests a TC Hash Value during the second GENERATE AC........................ 469 Terminal requests a TC on first GENERATE AC ........................................................ 470 Terminal requests an ARQC on first GENERATE AC................................................. 470 Terminal requests an AAC on first GENERATE AC.................................................... 471 Card responds with an ARQC on first GENERATE AC .............................................. 471 Card responds with an AAR on first GENERATE AC ................................................. 472 Card responds with a TC on first GENERATE AC...................................................... 473 Card responds with a AAC on first GENERATE AC ................................................... 473 Terminal requests an AAC on second GENERATE AC ............................................... 474 Cryptogram at a higher level than requested (1)......................................................... 474 Cryptogram at a higher level than requested (2)......................................................... 475 ERRONEOUS OR MISSING DATA IN ICC......................................................................................................... 475 2CL.001.00 Mandatory data objects missing: FCI.......................................................................... 475 2CL.002.00 Mandatory data objects missing: DF Name................................................................. 476 2CL.003.00 Mandatory data objects missing: SFI .......................................................................... 476 2CL.003.05 Mandatory data objects missing: DDF Name.............................................................. 477 2CL.004.00 Mandatory data objects missing: ADF Name .............................................................. 477 2CL.005.00 Mandatory data objects missing: Application Label.................................................... 478 2CL.006.00 Mandatory data objects missing: FCI Proprietary Template ...................................... 478 2CL.007.00 Mandatory data objects missing: AFL ......................................................................... 479 2CL.008.00 Mandatory data objects missing: AIP .......................................................................... 479 2CL.009.00 Mandatory data objects missing: CDOL1.................................................................... 480 2CL.010.00 Mandatory data objects missing: CDOL2.................................................................... 480 2CL.011.00 Mandatory data objects missing: PAN......................................................................... 481 2CL.012.00 Mandatory data objects missing: Application Expiration Date................................... 481 2CL.013.00 ATC not returned by GET DATA and Both LCOL and UCOL are present.................. 482 2CL.014.00 Last Online ATC Register not returned by GET DATA and Both LCOL and UCOL are present 483 2CL.015.00 CVM List not present and Cardholder Verification is supported in AIP ..................... 484 2CL.016.00 CA Public Key Index not present and Offline SDA is supported in AIP ...................... 485 2CL.017.00 CA Public Key Index not present and Offline DDA is supported in AIP ..................... 486 2CL.019.00 Issuer Public Key Certificate not present and Offline SDA is supported in AIP.......... 487 2CL.020.00 Issuer Public Key Certificate not present and Offline DDA is supported in AIP......... 488 2CL.021.00 Issuer Public Key Exponent not present and Offline SDA is supported in AIP ........... 489 2CL.022.00 Issuer Public Key Exponent not present and Offline DDA is supported in AIP........... 490 2CL.023.00 Issuer Public Key Remainder not present and Offline SDA is supported in AIP ......... 491 2CL.024.00 Issuer Public Key Remainder not present and Offline DDA is supported in AIP ........ 492 2CL.025.00 Signed Static Application Data not present and Offline SDA is supported in AIP ...... 493 2CL.026.00 ICC Public Key Certificate not present and Offline DDA is supported in AIP............ 494 2CL.027.00 ICC Public Key Exponent not present and Offline DDA is supported in AIP.............. 495 2CL.028.00 ICC Public Key Remainder not present and Offline DDA is supported in AIP ........... 496 2CL.029.00 Constructed Data Objects do not parse correctly: FCI of PSE ................................... 497 2CL.029.05 Constructed Data Objects do not parse correctly: Directory Record in Payment System Directory 497 2CL.030.00 Constructed Data Objects do not parse correctly: Record Template .......................... 498 2CL.031.00 Constructed Data Objects do not parse correctly: Application Template ................... 498 2CL.032.00 Constructed Data Objects do not parse correctly: FCI of ADF .................................. 499 2CL.033.00 Constructed Data Objects do not parse correctly: GPO response template................ 499 2CL.034.00 Constructed Data Objects do not parse correctly: GENERATE AC response template500 2CL.035.00 Constructed Data Objects do not parse correctly: INTERNAL AUTHENTICATE response template ................................................................................................................................... 500 2CL.036.00 Dates are out of the range............................................................................................ 501 2CK.003.00 2CK.004.00 2CK.005.00 2CK.006.00 2CK.007.00 2CK.008.00 2CK.009.00 2CK.010.00 2CK.011.00 2CK.012.00 2CK.013.00 2CK.015.00 2CK.017.00 2CK.018.00
Page 15

2CL.037.00 2CL.038.00 2CL.044.00 2CL.046.00 2CL.047.00 2CL.048.00 2CL.049.00 2CL.050.00 2CL.052.00 2CL.053.00 2CL.054.00 Data that must be in a specific range of values but are not: SFI ................................. 501 Data that must be in a specific range of values but are not: Issuer Code Table Index 502 CVM List with no Cardholder Verification Rules ........................................................ 502 AFL with no entries ...................................................................................................... 503 AFL with an incorrect SFI ........................................................................................... 503 AFL with an incorrect starting record number ............................................................ 504 AFL with an incorrect ending record number.............................................................. 504 AFL with an incorrect number of records participating in Offline Data Authentication505 ISO Padding: right padding......................................................................................... 505 ISO Padding: padding before Data object................................................................... 506 ISO Padding: padding between Data object................................................................ 506
ICC TERMINAL SPECIFICATION FOR PAYMENT SYSTEM, TEST CASE DESCRIPTION .. 507 GENERAL REQUIREMENTS ........................................................................................................................... 507 2CM.001.00 Merchant-controlled Terminal Provides Amount ...................................................... 507 2CM.002.00 Merchant-controlled Terminal Obtains Amount if Not Available............................... 508 2CM.003.00 Card Returns Error in Response to GET PROCESSING Command ......................... 508 2CM.004.00 Online Only Terminal Not Supporting Data Authentication Sets Bit......................... 509 2CM.006.00 Card and Terminal Application Version Numbers are different................................ 510 2CM.009.00 Terminal Recognition of CVM Codes ('No CVM required' supported)...................... 511 2CM.009.05 Terminal Recognition of CVM Codes ('No CVM required' not supported) ............... 512 2CM.010.00 Terminal Recognition of CVM Codes ('Fail CVM processing')................................ 513 2CM.011.00 Supported CVM.......................................................................................................... 513 2CM.012.00 PIN Try Counter......................................................................................................... 514 2CM.013.00 PIN Try Counter Not Retrievable by ICC .................................................................. 515 2CM.014.00 GET DATA Not Supported by ICC............................................................................. 516 2CM.015.00 Terminal Behaviour When PIN Try Counter Equals 0 .............................................. 517 2CM.016.00 Terminal Prompt for PIN Entry (PIN Try Counter >0) ............................................. 518 2CM.017.00 CVM is Set When Offline PIN is Successful ............................................................... 519 2CM.018.00 Offline PIN Not Successful......................................................................................... 520 2CM.019.00 Online PIN used for CVM .......................................................................................... 521 2CM.020.00 Online PIN When PIN Try Limit is Exceeded and Terminal Supports GET DATA for PIN Try Counter 522 2CM.020.01 Online PIN When PIN Try Limit is Exceeded and the Terminal does not support GET DATA for PIN Try Counter..................................................................................................................... 523 2CM.021.00 CVM Results Set for Online PIN ................................................................................ 524 2CM.022.00 TVR is Set When PIN Entry is bypassed at Attended Terminal.................................. 525 2CM.023.00 CVM unsuccessful When PIN Entry is bypassed at Attended Terminal..................... 526 2CM.024.00 CVM is Set to unknown When Signature is Used .................................................... 527 2CM.025.00 Terminal Prints Receipt With Line for Cardholder Signature ................................... 528 2CM.026.00 CVM is Set When no CVM is Required ...................................................................... 529 2CM.027.00 CVM is Set When CVM is Fail CVM Processing .................................................... 529 2CM.028.00 CVM Results Set With Method Code and Condition Code of Last CVM Performed . 530 2CM.029.00 CVM Results Set When Last CVM Not Considered Successful .................................. 531 2CM.030.00 CVM Results Set When No CVM Was Performed ...................................................... 532 2CM.031.00 Terminal Checks Presence of Application Selected ................................................... 533 2CM.032.00 TVR Set if Match is Found in Exception File............................................................. 534 2CM.033.00 Authorization Response Code Set When Terminal Accepts Transaction Offline ........ 535 2CM.034.00 Authorization Response Code Set When Terminal Declines Transaction Offline...... 535 2CM.035.00 Authorization Response Code Not Set When Terminal Opts To Transmit Transaction Online 536 2CM.036.00 Terminal Completes Transaction When Card Indicated Approval ............................ 536 2CM.037.00 Terminal Declines Transaction When Card Indicated Denial................................... 537
Page 16

2CM.038.00 Terminal Transmits Auth. or Financial Transaction Request Message ..................... 537 2CM.039.00 Terminal Performs Referrals if Card Indicates a Referral ........................................ 538 2CM.040.00 Advice is Requested by Card and is Supported by the Terminal and transaction is captured 538 2CM.041.00 Advice is Requested by Card and is Supported by the Terminal and transaction is not captured 539 2CM.042.00 Terminal Terminates Transaction if Card Indicates Service Not Allowed .............. 539 2CM.042.06 Combined DDA/AC Generation failed and ICC returned an ARQC ......................... 540 2CM.043.00 Terminal Decides To Accept or Decline Transaction and Issues 2nd GENERATE AC541 2CM.044.00 Authorization Response Code is Online Approved.................................................. 542 2CM.045.00 Terminal Support of Issuer Scripts in Authorization or Financial Transaction Response 543 2CM.048.00 Terminal Reporting of Script Identifier...................................................................... 543 2CM.049.00 Issuer Script Results Set When Error Code Was Returned by Card ........................... 544 2CM.050.00 Issuer Script Results Set When No Error Code Was Returned by Card...................... 545 2CM.051.00 Terminal Transmission of Issuer Script Results.......................................................... 546 2CM.052.00 Terminal Creates an Advice When No Message is Created for Transaction .............. 547 2CM.055.00 Terminal Supporting DDA Shall Support SDA .......................................................... 548 2CM.056.00 Offline Only Terminal Shall Support SDA ................................................................. 549 2CM.057.00 Offline Terminal With Online Capability Shall Support SDA.................................... 550 2CM.058.00 Offline Only Terminal Shall Support Terminal Risk Management ............................ 551 2CM.059.00 Offline Terminal With Online Capability Shall Support Terminal Risk Management552 2CM.060.00 Financial Institution Terminal Supports TRM ............................................................ 553 2CM.061.00 Merchant Controlled Terminal Supports TRM .......................................................... 554 2CM.062.00 Terminal Displays Amount of Transaction ................................................................ 555 2CM.063.00 Cashback Amount is Transmitted in the Amount, Other Data Object........................ 555 2CM.064.00 Purchase and Cashback Transmitted in Amount Authorised ............................................ 556 2CM.066.00 Authorised Amount Is Expressed With Implicit Decimal Point.................................. 557 2CM.067.00 Other Amount Is Expressed With Implicit Decimal Point.......................................... 558 2CM.068.00 Attended Terminal Displays Message When Card Requests Voice Referral.............. 559 2CM.069.00 Application Data Displayed or Printed To Perform Referral initiated by card......... 559 2CM.070.00 Messages Displayed For Attendant to Indicate Approval or Denial of a Referral initiated by card 560 2CM.071.00 Authorization Response Code Set as a Result of Referral Process initiated by card. 561 2CM.072.00 Terminal Issues Second GENERATE AC command as a Result of Referral Process initiated by card 562 2CM.073.00 Terminal Behaviour When Transaction is Forced Online ......................................... 563 2CM.074.00 Terminal Displays Message To Attendant When Issuer Requests Voice Referral...... 564 2CM.075.00 Data Displayed or Printed to Perform Referral initiated by issuer ........................... 565 2CM.076.00 Messages Displayed Requesting Attendant to Indicate Approval or Denial of a Referral initiated by issuer ..................................................................................................................... 566 2CM.077.00 Authorization Response Code when Referral is initiated by Issuer ........................... 567 2CM.078.00 Terminal Issues Second GENERATE AC................................................................... 568 2CM.079.00 TVR Set When Merchant Forces Transaction Online ................................................ 569 2CM.080.00 Attendant forces Approval of the Transaction ............................................................ 569 2CM.081.00 Authorization Response Code when acceptance is forced .......................................... 570 2CM.082.00 Terminal Sets Indicator When Attendant forces Approval of the Transaction............ 571 2CM.083.00 Terminal Maintains Transaction Sequence Counter................................................... 571 2CM.085.00 Generation of Unpredictable Number......................................................................... 572 2CM.086.00 Terminal Reading of Service Code on Magnetic Stripe .............................................. 572 2CM.087.00 Terminal Reading of Service Code on Magnetic Stripe .............................................. 573 2CM.091.00 POS Entry Mode Code Read....................................................................................... 574 2CM.092.00 Calculation of Dates Associated With Data Authentication ....................................... 575 2CM.093.00 Calculation of Dates Associated With Processing Restrictions .................................. 576 2CM.094.00 Calculation, Storage, and Display Date-Dependant Fields For Year 2000 + ........... 577
Page 17

2CM.095.00 Processing the Year ................................................................................................... 578 2CM.096.00 Colouring of Command Keys ...................................................................................... 578 2CM.099.00 Numeric and Command Keys on PIN Pad .................................................................. 579 2CM.100.00 Numeric Layout of PIN Pad........................................................................................ 579 2CM.102.00 Display For Attendant for Attended Terminal ............................................................ 580 2CM.103.00 Display of Alphanumeric Characters.......................................................................... 580 2CM.104.00 Protection of Software and Data................................................................................. 581 2CM.105.00 Protection of Captured Transactions and Advices Stored .......................................... 581 2CM.106.00 Clock With Local Date and Time ................................................................................ 582 2CM.107.00 Capability of Terminal Printer.................................................................................... 582 2CM.108.00 Terminal Also Equipped With Magnetic Stripe Reader .............................................. 583 2CM.109.00 Magnetic Stripe Reader Using Full Track 1 and/or Track 2 ...................................... 583 2CM.129.00 PIN Pad Shall Support Entry of 4-12 Digit PIN ......................................................... 584 2CM.130.00 Display of Indication of Entry on PIN Pad ................................................................. 585 2CM.131.00 Protection of Values of Entered PIN........................................................................... 586 2CM.137.00 Protection of PIN During Online PIN Verification..................................................... 587 2CM.140.00 Amount Entry Process Separate From PIN Entry Process ......................................... 588 2CM.141.00 Amount Validated by Cardholder ............................................................................... 589 2CM.142.00 Enhanced Combined DDA/AC failed at 2nd generate AC .......................................... 590 2CM.143.00 Combined DDA/AC generation requested bit in Generate AC .................................. 591 SOFTWARE ARCHITECTURE .......................................................................................................................... 592 2CN.004.00 Data Elements are Initialised in Terminal................................................................... 592 2CN.012.00 Language Support by Terminal ................................................................................... 594 2CN.016.00 Terminal Displays Error Message if Verification Process fails .................................. 595 CARDHOLDER AND ATTENDANT INTERFACE ................................................................................................ 595 2CO.001.00 Terminal Support of Local Language.......................................................................... 595 2CO.002.00 Terminal Display of Messages in Local Language...................................................... 596 2CO.003.00 Terminal Support of Relevant Character Set............................................................... 596 2CO.005.00 Terminal uses language With Highest Preference....................................................... 597 2CO.006.00 Terminal Allows Cardholder to Select Language........................................................ 598 2CO.007.00 Terminal Displays Message in Selected Language...................................................... 599 2CO.008.00 Terminal Displays Message in Supported Language .................................................. 600 2CO.011.00 Terminal Support of Explicit Selection ........................................................................ 600 2CO.013.00 Terminal Creates a List of Applications Supported (1) ............................................... 601 2CO.014.00 Terminal Creates a List of Applications Supported (2) ............................................... 602 2CO.015.05 Terminal Presents Application List ............................................................................. 603 2CO.016.00 Terminal Selects Application With Next Highest priority............................................ 604 2CO.017.00 Application Used Identified on Receipt ....................................................................... 605 2CO.018.00 Data Printed on Receipt .............................................................................................. 605 2CO.019.00 Authorization Message Used ....................................................................................... 606 2CO.020.00 Financial Transaction Message Used ......................................................................... 606 2CO.021.00 Offline Advice message Conveyed ............................................................................... 607 2CO.023.00 Reversal Used .............................................................................................................. 607 2CO.025.00 Terminal Issues a 2nd GENERATE AC Command When Unable to Go Online (1).... 608 2CO.026.00 Terminal Issues a 2nd GENERATE AC Command When Unable to Go Online (2).... 609 2CO.027.00 Issuer Authentication was performed Bit is Set.......................................................... 610 2CO.028.00 Terminal Continues Processing Based on Authorization Response Code................... 611 2CO.029.00 Repeat of Authorization Request.................................................................................. 612 2CO.030.00 Terminal Issues a 2nd GENERATE AC Command (1) ................................................ 613 2CO.031.00 Terminal Issues a 2nd GENERATE AC Command (2) ................................................ 614 2CO.032.00 Terminal Sends Reversal Message............................................................................... 615 2CO.033.00 Terminal Creates Financial Record ............................................................................ 616 2CO.034.00 Terminal Terminates Processing of Issuer Script........................................................ 617
Page 18

2CO.035.00 Terminal Reports in Issuer Script results .................................................................... 618 2CO.036.00 Terminal Continues Processing any Subsequent Issuer Script.................................... 619 CODING OF TERMINAL DATA ELEMENTS...................................................................................................... 620 2CP.001.00 Terminal Type .............................................................................................................. 620 2CP.002.00 Terminal Capabilities................................................................................................... 621 2CP.003.00 Additional Terminal Capabilities ................................................................................. 622
Page 19
Scope
Integrated Circuit Card Specification for Payment System Version 4.0 is now divided in 4 books: Book 1: Application Independent ICC to Terminal Interface Requirements Book 2: Security and Key Management Book 3: Application Specification Book 4: Cardholder, Attendant, and Acquirer Interface Requirements
The Book 1 (Part II) and Book 2 define the complete flow of a transaction between an Integrated Circuit Card (ICC) and a terminal, from the selection of an application in the ICC to the completion of the transaction. Book 3 defines the format of ICC commands used during the transaction flow between the ICC and terminal. Also defined is the transaction flow and associated data for an application compliant with the EMV specifications. Finally Book 4 defines the characteristics of a Terminal that supports an ICC conforming to the two previous specifications mentioned. The 4 Books are divided in testable requirements listed in the 'EMVCo Terminal Level 2 Type Approval - Requirements'. The present document, 'EMVCo Terminal Level 2 Type Approval - Test Cases List', describes a set of test cases which when applied to the terminals, are designed to determine whether the terminal meets the requirements stated in EMV2000 Integrated Circuit Card Specification for Payment Systems Version 4.0 dated December 2000. Test cases are defined for unitary tests that are performed without presence of a valid EMV payment application and functional testing dependent of the presence of the EMV payment application. Terminal/host protocol (if present) is not tested since requirements for terminal communication with external components is not defined by EMV specifications. If any special conditions are required for a specific test case, these conditions are described in the test case. The intended audience for this document are EMVCo accredited laboratories, EMV application providers, acquiring members or merchants. Although acquiring members and merchants may reference this document, type approval testing oriented toward EMV application providers.
Page 20
Referenced Documents
[N1] EMV 2000 Integrated Circuit Card Specification for Version 4.0 - December Payment Systems - Book 1 - Application Independent 2000 ICC to Terminal Interface Requirements EMV 2000 Integrated Circuit Card Application Version 4.0 - December Specification for Payment Systems - Book 2 - 2000 Security and Key Management EMV 2000 Integrated Circuit Card Terminal Version 4.0 - December Specification for Payment Systems - Book 3 - 2000 Application Specification EMV 2000 Integrated Circuit Card Terminal Version 4.0 - December Specification for Payment Systems - Book 4 - 2000 Cardholder, Attendant, and Acquirer Interface Requirements
[N2]
[N3]
[N4]
Page 21
Abbreviations and Notations

APDU ATR C-APDU CLA C-TPDU EMV ICC IFD INS ISO Lc Le Application Protocol Data Unit Answer to Reset Command APDU Class Byte of the Command Message Command TPDU Europay, MasterCard, Visa Integrated Circuit Card Interface Device Instruction Byte of Command Message International Organization for Standardization Exact Length of Data Sent by the TAL in a Case 3 or 4 Command Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Exact Length of Data Available or Remaining in the ICC (as Determined by the ICC) to be Returned in Response to the Case 2 or 4 Command Received by the ICC Length Length of Response Data Field Least Significant Most Significant Length of the Certification Authority Public Key Modulus Length of the Issuer Public Key Modulus Copyright 2002 EMVCo, LLC. All rights reserved Page 22
Licc
LEN Lr l.s. m.s. NCA NI
EMVCo Type Approval - Terminal Level 2 - Test Cases NIC P1 P2 P3 PI PIC R-APDU RST R-TPDU SCA SI SIC SW1 SW2 TPDU Length of the ICC Public Key Modulus Parameter 1 Parameter 2 Parameter 3 Issuer Public Key ICC Public Key Response APDU Reset Response TPDU Certification Authority Private Key Issuer Private Key ICC Private Key Status Word One Status Word Two Transport Protocol Data Unit
Page 23
Global Glossary
Accelerated Revocation- A key revocation performed date sooner than the published key expiry date. Accreditation - Formal recognition by EMVCo that an auditor or testing laboratory is competent to carry out specific functions defined in EMVCo type approval procedures. Acquirer - A financial institution that supports merchants by providing services for processing payment card transactions. Acquirer System - A logical entity that provides electronic commerce services to the merchants in support of the acquirer and interfaces to the acquirer to support the authorization and capture of electronic commerce transactions. Answer to Reset (ATR) - A string of bytes sent by the integrated circuit card (ICC) in response to the reset by the terminal. These bytes convey information to the terminal that define certain characteristics of the communication to be established between the ICC and the terminal. Application - The application protocol between the card and the terminal and its related set of data. Application Protocol Data Unit (APDU) - A message sent from the interface device (IFD) to the card or conversely. It may contain either a command message or a response message. Asymmetric Cryptographic Technique - A cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is computationally infeasible to derive the private transformation. Auditor - Independent impartial entity that verifies test laboratory conformance to EMVCo defined type approval procedures. Authentication- The provision of assurance of the claimed identity of an entity [ISO/IEC 10181-2: 1996]. Authorization- The process by which a properly appointed person or persons grants permission to perform some action on behalf of an organization. This process assesses transaction risk, confirms that a given transaction does not raise the account holder's debt above the account's credit limit, and reserves the specified amount of credit. (When a merchant obtains authorization, payment for the authorized amount is guaranteed - provided that the merchant followed the rules associated with the authorization process.)
Page 24
EMVCo Type Approval - Terminal Level 2 - Test Cases Authorization Reversal - A transaction sent when a previous authorization needs to be canceled (a full reversal) or decreased (a partial reversal). A full reversal will be used when the transaction can not be completed, such as when the cardholder cancels the order or the merchant discovers that the goods are no longer available, as when discontinued. A partial reversal will be used when the authorization was for the entire order and some of the goods cannot be shipped, resulting in a split shipment. Block - A succession of characters comprising two or three fields defined as prologue field, information field, and epilogue field. Byte - 8 bits. Card - A payment card as defined by a payment system. Cardholder - An authorized holder of a payment card supported by an issuer. Cardholder System - The combination of hardware and software required to interact with the cardholder, his or her IC Card, and a SET Merchant Server in order to participate in EMV chip electronic commerce. Certificate: The public key and identity of an entity together with some other information, rendered unforgeable by signing with the secret key of the certification authority which issued that certificate. Certificate Revocation: The process of revoking an otherwise valid certificate by the entity that issued that certificate. Certification Authority: A centre trusted to create and assign public key certificates which provide evidence linking a public key and other relevant information to its owner. Certification Authority - Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Ciphertext - Enciphered information. Cold Reset - The reset of the ICC that occurs when the supply voltage (VCC) and other signals to the ICC are raised from the inactive state and the reset (RST) signal is applied. Command - A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Compromise: The breaching of secrecy or security. Concatenation - Two elements are concatenated by appending the bytes from the second element to the end of the first. Bytes from each element are represented in the resulting string in the same sequence in which they were presented to the terminal by the ICC, that is, most significant byte first. Within each byte bits are ordered from most significant bit to least significant. A list of elements or objects may be concatenated by concatenating the first pair to form a new element, using that as the first element to concatenate with the next in the list, and so on. Copyright 2002 EMVCo, LLC. All rights reserved Page 25
EMVCo Type Approval - Terminal Level 2 - Test Cases Conformance - Meeting all the requirements (and also any optional requirements) that the interface module (IFM) provider instituted of that specification. Contact - A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Contact Interface - The area where a contact if the interface device (IFD) physically touches a contact on the integrated circuit card (ICC) allowing an electrical current to flow between the contacts. Cryptogram - Result of a cryptographic operation. Cryptography- The practice of digitally "scrambling" a message using a secret key or keys. These keys are used to unscramble or decrypt the message. Cryptoperiod: Defined period of time during which a specific cryptographic key is authorized for use, or during which time the cryptographic keys for a given system may remain in effect. (ISO 8908) Cryptographic Algorithm - An algorithm that transforms data in order to hide or reveal its information content. Data Integrity - The property that data has not been altered or destroyed in an unauthorised manner Data Key (KD): Cryptographic key used for the encipherment, decipherment or authentication of data. (ISO 8908) Decipherment: Process of transforming cipher text into plain text - the reversal of a corresponding encipherment. Declaration of conformity - Written statement by an interface module (IFM) provider claiming that their production of a specific IFM type is in conformance with all related specifications, as defined by EMVCo. Digital Envelope - A cryptographic technique to encrypt data and send the encryption key along with the data. Generally, a symmetric algorithm is used to encrypt the data and an asymmetric algorithm is used to encrypt the encryption key. Digital Signature - An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data, and protect the sender and the recipient of the data against forgery by third parties, and the sender against forgery by the recipient. Electronic Commerce - The exchange of goods and services for payment between the cardholder and merchant when some or all of the transaction is performed via electronic communication. Copyright 2002 EMVCo, LLC. All rights reserved Page 26
EMVCo Type Approval - Terminal Level 2 - Test Cases Electronic Commerce Access Device - The combination of hardware and software required to interact with the cardholder, the ICC, and an electronic commerce system in order to conduct EMV-based electronic commerce purchases. Embossing - Characters raised in relief from the front surface of a card. EMVCo - Legal structure created by Europay International S.A., MasterCard International Incorporated, and Visa International Service Association for including, but not limited to, smart card interoperability specifications and associated type approval procedures. EMVCo test authority - The entity responsible for the type approval process. Encipherment - The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Epilogue Field - The final field of a block. It contains the error detection code (EDC) byte(s). Expiry Date: Date after which a financial instrument or agreement ceases to be valid. External operating conditions (EOC) - In addition to the implementation conformance statement (ICS), this document describes the setup and handling of the system under test (SUT) before and during the type approval tests, and describes the environmental conditions and maximum rating the interface module (IFM) is designed for. The IFM provider in cooperation with the testing laboratory defines this document. Financial Transaction - The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. Function - A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. Guardtime - The minimum time between the trailing edge of the parity bit of a character and the leading edge of the start bit of the following character sent in the same direction. Hash Function - A function that maps strings of bits to fixed-length strings of bits, satisfying the following two properties: It is computationally infeasible to find for a given output an input which maps to this output. It is computationally infeasible to find for a given input a second input that maps to the same output. Additionally, if the hash function is required to be collision-resistant, it must also satisfy the following property: It is computationally infeasible to find any two distinct inputs that map to the same output. Copyright 2002 EMVCo, LLC. All rights reserved Page 27
EMVCo Type Approval - Terminal Level 2 - Test Cases Hash Result - The string of bits that is the output of a hash function. Implementation conformance statement (ICS) - A form completed by the interface module (IFM) provider. The written statement lists all optional functions as specified in the reference specification implemented in the interface module (IFM). It includes the identification description and external operating conditions (EOC) of the IFM. Implementation under test (IUT) - A virtual or abstract device, implementing the EMV specification, to be submitted for testing (a view of the interface module (IFM) is attached to the design). Inactive - The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0.4 V or less with respect to ground (GND). Installation guideline - Set of guidelines, delivered by the interface module (IFM) provider with every IFM, describing under what conditions a terminal or an IFM can be installed. Integrated Circuit(s) - Electronic component(s) designed to perform processing and/or memory functions. Integrated Circuit(s) Card - A card into which one or more integrated circuits are inserted to perform processing and memory functions. Integrated Circuit Module - The sub-assembly embedded into the ICC comprising the IC, the IC carrier, bonding wires, and contacts. Interface Device - That part of a terminal into which the ICC is inserted, including such mechanical and electrical devices that may be considered part of it. Interface Module - A virtual or abstract device attached to a type production configuration implemented as a physical device included in a terminal. Interoperability - The ability of the software and hardware from different interface module (IFM) providers to work together. Issuer - A financial institution that supports issuing payment card products to individuals. Key - A sequence of symbols that controls the operation of a cryptographic transformation. Key Activation: The process of beginning to use a key at the Certification Authority for the production of public key certificates. Key Expiry Date: The date after which a signature made with a particular key is no longer valid. Issuer certificates signed by the key must expire on or before this date. Keys may be removed from terminals after this date has passed. Copyright 2002 EMVCo, LLC. All rights reserved Page 28
EMVCo Type Approval - Terminal Level 2 - Test Cases Key Installation Deadline: The date by which all terminals must be able to verify issuer certificates based on this key, and the earliest date that cards may be issued that contain issuer certificates based on this key. Key Introduction: The process of generating, distributing, and beginning use of a key pair. Key Life Cycle: All phases of key management, from planning and generation, through revocation, destruction, and archiving. Key Replacement: The simultaneous revocation of a key and introduction of a key to replaced the revoked one. Key Revocation: The key management process of withdrawing a key from service and dealing with the legacy of its use. Key revocation can be as-scheduled or accelerated. Key Revocation Date: The date after which no legitimate cards still in use should contain certificates signed by this key, and therefore the date after which this key can be deleted from terminals. For a planned revocation the Key Revocation Date is the same as the key expiry date. Key Withdrawal: The process of removing a key from service as part of its revocation. Laboratory - A facility that performs type approval testing. Letter of accreditation - Written statement that confirms a testing laboratory is performing type approval tests in conformance to the common rules, as defined by EMVCo. Letter of approval - Written statement that documents the decision of the EMVCo Test Authority that a specified product type has demonstrated sufficient conformance to the EMV specification. Level 1 Test - The execution of a defined set of electrical, mechanical, and communication protocol tests versus requirements described in Part 1 of the EMV Integrated Circuit Card Specification for Payment Systems. Logical Compromise: The compromise of a key through application of improved cryptanalytic techniques, increases in computing power, or combination of the two. Lower tester - The integrated circuit card (ICC) simulator going to allow the implementation under test (IUT) to react on normal and error conditions. Magnetic Stripe - The stripe containing magnetically encoded information. Maintenance guideline - Set of guidelines, delivered by the interface module (IFM) provider with every IFM, describing under what conditions a terminal or an IFM can be maintained. Major modification - Technical change of an interface module (IFM) or its functionality that implies that the IFM provider can no longer guarantee conformance of the modified Copyright 2002 EMVCo, LLC. All rights reserved Page 29
EMVCo Type Approval - Terminal Level 2 - Test Cases IFM with the requirements of Part 1 of the EMV Integrated Circuit Card Specification for Payment Systems. Merchant - A seller of goods, services, and/or information who accepts payment for them electronically, and may provide selling services and/or electronic delivery of items for sale (e.g., information). Merchant Server - A system that interacts with the Cardholder System for electronic payments. The Merchant Server also interacts with the Acquirer using the payment protocol to receive authorization and capture services for electronic payment transactions. Merchant System - A system that interfaces with the cardholder (or ECAD) to offer goods and services in return for electronic payment and interfaces with the acquirer system to process electronic commerce transactions. Message - A string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. Message Authentication Code - A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. Migration Key- A key introduced into the system for future use. Minor modification - Technical change of an interface module (IFM) or its functionality that does not impact the functionality of that IFM with respect to the requirements of Part 1 of the Integrated Circuit Card Specification for Payment Systems and the implementation conformance statement (ICS). Network - A collection of communication and information processing systems that may be shared among several users. Nibble - The four most significant or least significant bits of a byte. Padding - Appending extra bits to either side of a data string. Path - Concatenation of file identifiers without delimitation. Payment System - For the purposes of this specification, Europay International S.A., MasterCard International Incorporated, or Visa International Service Association. Payment Systems Environment - The set of logical conditions established within the ICC when a payment system application conforming to this specification has been selected, or when a directory definition file (DDF) used for payment system application purposes has been selected. Physical Compromise: The compromise of a key resulting from the fact that it has not been securely guarded, or a hardware security module has been stole or accessed by unauthorised persons. Copyright 2002 EMVCo, LLC. All rights reserved Page 30
EMVCo Type Approval - Terminal Level 2 - Test Cases Plaintext - Unenciphered information. Planned Revocation: A key revocation performed as scheduled by the published key expiry date. Potential Compromise: A condition where cryptanalytic techniques and/or computing power has advanced to the point that compromise of a key of a certain length is feasible or even likely. Primary Account Number (PAN) - The assigned number that identifies the card issuer and cardholder. This account number is composed of an issuer identification number, an individual account number identification, and an accompanying check digit, as defined by ISO 7812-1985. Private Key - That key of an entitys asymmetric key pair that should only be used by that entity. In the case of a digital signature scheme, the private key defines the signature function. Proficiency - Ability of a testing laboratory to perform the specified tests in an exact and reproducible fashion and to provide an accurate test report. Prologue Field - The first field of a block. It contains subfields for node address (AD), protocol control byte (PCB), and length (LEN). Protocol - Method of communication between the integrated circuit card (ICC) and the terminal, represented in this specification by T=0 (character protocol) and T=1 (block protocol). Prototype - Implementation of a design for evaluation purposes but not for type approval. Public Key - That key of an entitys asymmetric key pair that can be made public. In the case of a digital signature scheme, the public key defines the verification function. Public Key Certificate - The public key information of an entity signed by the certification authority and thereby rendered unforgeable. Quality assurance - For purpose of this specification, all activities targeted at maximizing the level of confidence that the quality of a product is constant and demonstrated throughout volume production. Quality system - An organization implementing quality procedures describing the operations performed by its people in order to achieve its activity with the correct level of quality. Redundancy - Any information that is known and can be checked. Reference specification - A set of documents defining the requirements to which the interface module (IFM) shall comply. The reference specification consists of the current EMV Integrated Circuit Card Specification for Payment Systems and any additional documentation required to proceed with type approval. Copyright 2002 EMVCo, LLC. All rights reserved Page 31
EMVCo Type Approval - Terminal Level 2 - Test Cases Registration Authority An independent third-party organization that process payment card applications for multiple payment card brands and forwards applications to the appropriate financial institutions. Response - A message returned by the ICC to the terminal after the processing of a command message received by the ICC. RSA Failure: An advance in mathematics, cryptanalysis or technology that renders RSA key technology ineffective, regardless of key or key size. Sample - Terminal, including the implementation under test (IUT), picked out of production for testing. Secret Key - A key used with symmetric cryptographic techniques and usable only by a set of specified entities. Script - A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Secure Socket Layer (SSL) - a standard (developed by Netscape Communications Company) that encrypts data between a Web browser and a Web server. SSL does not specify what data is sent or encrypted. In an SSL session, all data sent is encrypted. Service provider - The entity that provides a product or a service to customers, using terminals and a payment system. Signal Amplitude - The difference between the high and low voltages of a signal. Signal Perturbations - Abnormalities occurring on a signal during normal operation such as undershoot/overshoot, electrical noise, ripple, spikes, crosstalk, etc. Random perturbations introduced from external sources are beyond the scope of the specification. State H - Voltage high on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. State L - Voltage low on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. Statement of readiness - Part of the implementation conformance statement (ICS); it is a declaration by the interface module (IFM) provider that the IFM type conforms to the EMV specifications. Statement of specification acceptance- Written statement from the interface module (IFM) provider that states the IFM provider accepts all related specifications as defined by EMVCo.
Page 32
EMVCo Type Approval - Terminal Level 2 - Test Cases Suspected Compromise: A condition where information from system monitoring indicates malfunction which could be caused by key compromise, but which has not been confirmed as such. Symmetric Cryptographic Technique - A cryptographic technique that uses the same secret key for both the originators and recipients transformation. Without knowledge of the secret key, it is computationally infeasible to compute either the originators or the recipients transformation. System integrator - The entity that integrates interface modules (IFMs) and devices containing IFMs into a system for use by a service provider. System under test (SUT) - System, module, part, or component actually tested or to be tested (either a part of the terminal or the entire terminal) including the implementation under test (IUT). T=0 - Character-oriented asynchronous half-duplex transmission protocol. T=1 - Block-oriented asynchronous half-duplex transmission protocol. Template - Value field of a constructed data object, defined to give a logical grouping of data objects. Terminal - The device used in conjunction with the ICC at the point of transaction to perform a financial transaction. It incorporates the interface device and may also include other components and interfaces such as host communications. Terminal application layer (TAL) - The part of the terminal that initiates a command. It sends an instruction via the terminal transport layer (TTL) to the integrated circuit card (ICC) in the form of a five-byte header called the command header. Test - Any activity that aims at verifying the conformance of a selected product or process to a given requirement under a given set of conditions. Test bench - A defined combination of a set of test methods and test equipment for the purpose of type approval tests. Type Approval - Acknowledgment by EMVCo that the specified product has demonstrated sufficient conformance to the EMVCo ICC specifications for its stated purpose. Type Approval documentation - Full set of documents and procedures issued by EMVCo to perform the type approval process. Type Approval process - The processes followed to test a product type for compliance with a certain specification. Type Approval test - The execution of a defined set of tests against requirements described in a specification to determine compliance with that specification. Type approval test report - The result of type approval testing on a product. Copyright 2002 EMVCo, LLC. All rights reserved Page 33
EMVCo Type Approval - Terminal Level 2 - Test Cases Upper tester - The internal (or back external) application of the interface module (IFM) that emulates a real application in order to test the implementation under test (IUT) under all possible conditions. Warm Reset - The reset that occurs when the reset (RST) signal is applied to the ICC while the clock (CLK) and supply voltage (VCC) lines are maintained in their active state.
Page 34
Command Syntax
The intent of the test cases in this Section is to verify that the commands are in accordance with EMV 2000 Integrated Circuit Card Specifications for Payment Systems - Part I - Book 3 Application Specification. While the application will be utilized to perform command syntax checking, functionality testing will not be specifically checked, but will be tested in other sections as specified.
Page 35
2CS.001.00 Mandatory Command Set

Test No. 2CS.001.00 Objective: To ensure that all terminals issue the basic mandatory commands in the correct
format and issues them at the expected times during the transaction flow.
Reference: 2RA.039.0 - Book 3 Section 2.5.5.2 - Syntax of GENERATE AC Command 2RA.039.5 - Book 3 Section 2.5.5.3 - Syntax of GENERATE AC Command Data Field 2RA.045.0 - Book 3 Section 2.5.8.2 - Syntax of GET PROCESSING OPTIONS Command 2RA.058.5 - Book 3 Section 2.5.11.3 & Book 1 Section 7.2.3 - Syntax of READ RECORD command Data Field 2RA.060.0 - Book 1Section 7.3.2 - Syntax of SELECT Select command 2RA.061.0 - Book 1Section 7.3.2 - Syntax of SELECT Select command: P2 parameter Conditions: ICC contains AIP value 00 00 Card does not support additional functionality
ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2)
All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'

All IAC (Denial/online/default) in LT are set up to '00 00 00 00 00'
For Generate AC Command P1=40 Procedure:

The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Terminal Action Analysis Completion. Terminal shall process the card to completion. Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command
Pass Criteria:

Page 36

00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL) Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on AFL Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 37
2CS.002.00 Select Next Command

Test No. 2CS.002.00 Objective: To ensure the terminal issues the Select Next command in the correct format and
issued at the expected times during the transaction flow.
Reference: 2RA.061.0 - Book 1Section 7.3.2 - Syntax of SELECT Select command: P2 parameter Conditions:
ICC contains DF name longer than the terminal stored AID ICC contains AIP value 00 00 Card does not support additional functionality ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
Procedure:
For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Terminal Action Analysis
Completion. Pass Criteria:

Terminal shall process the card to EMV transaction completion Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. Terminal shall issue Select next command in response to receiving a Dfname longer than the AID stored in the terminal. Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Select Next: Mandatory Command 00 A4 04 02 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL)
Page 38

Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 39
2CS.003.00 Internal Authenticate Command

Test No. 2CS.003.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, the internal
authenticate command is properly issued.
Reference: 2RA.053.0 - Book 3 Section AUTHENTICATION command
2.5.9.2
Syntax Syntax
of of
INTERNAL INTERNAL
2RA.054.0 - Book 3 Section 2.5.9.3 AUTHENTICATION command Data Field Conditions:

ICC contains AIP value 20 00 Offline DDA is supported ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) ICC contains required Data Objects to support DDA All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
Procedure:
All IAC (Denial/online/default) in LT are set up to '00 00 00 00 00' For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Data Authentication Terminal Action Analysis Completion. Terminal shall process the card to transaction completion Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. Terminal shall issue Internal Authenticate command after Read st Application Data but prior to 1 Gen AC command Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL) Le = (Not Present T=0)
Pass Criteria:

Page 40

Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. Internal Authenticate: Authentication Mandatory if terminal supports Dynamic Data
00 88 00 00 Lc Command Data Le Lc = (Length of Command Data) Command Data = Length of authentication-related data Le = 00 (Not Present for T=0) Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 41
2CS.004.00 Verify Command

Test No. 2CS.004.00 Objective: To ensure that terminal supporting Cardholder verification form, Plaintext PIN
verified by ICC, issues the Verify Command in the correct format and is issued at the expected time during the transaction flow. If the terminal supports Get Data for PIN try counter, the Get Data command will be issued prior to the Verify command.
Reference: 2RA.066.0 - Book 3 Section 2.5.12.2 - Syntax of VERIFY command 2RA.067.0 - Book 3 Section 2.5.12.2 - Syntax of VERIFY command: P2 parameter Conditions:
ICC contains AIP value 10 00 Cardholder verification is supported ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) ICC contains CVM list, tag 8E contains CVR 0100 i.e. plain text PIN verified by ICC always. Terminal supports plain text PIN All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
Procedure:
For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Cardholder Verification Terminal Action Analysis Terminal shall process the card to transaction completion. Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. If terminal supports Get Data for PIN try counter, it shall be issued prior to the Verify Command. Terminal shall issue Verify Command after Read Application Data but prior st to 1 GEN AC. Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0)
Completion. Pass Criteria:

Page 42

Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL) Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. Get Data For PIN Try Counter: If Terminal Supports 80 CA 9F 17 00 Lc = Not Present Command Data = Not Present Verify Command 00 20 00 P2 Lc Command Data Le P2 = Qualifier (80 plaintext) Command Data (Transaction Pin Data) Le = (Not Present) Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 43
2CS.005.00 Get Challenge

Test No. 2CS.005.00 Objective: To ensure to the terminal issues the Get Challenge and Verify command in the
correct format and issues them at the expected times during the transaction flow if the terminal supports Cardholder verification form, Enciphered PIN verified by ICC. If the terminal supports Get Data command for PIN Try counter, it shall be issued prior to the Verify command.
Reference: 2RA.072.0 - Book 3 Section 2.5.6.2 - Syntax of GET CHALLENGE command 2RA.072.5 - Book 3 Section 2.5.6.3 - Syntax of GET CHALLENGE command Data Field 2RA.067.0 - Book 3 Section 2.5.12.2 - Syntax of VERIFY command: P2 parameter Conditions:
ICC contains AIP value 10 00 Cardholder verification is supported ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) CVM list tag 8E contains CVR 0400 i.e. Enciphered PIN verified by ICC always. ICC contains all mandatory data objects to support Enciphered PIN Terminal supports Enciphered PIN All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
Procedure:
All IAC (Denial/online/default) in LT are set up to '00 00 00 00 00' For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Cardholder Verification Terminal Action Analysis Completion. Terminal shall process the card to transaction completion Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. If the Terminal supports Get Data for PIN Try Counter, it will be issued prior to the Verify command. Terminal shall issue Get Challenge command after Read Application Data but prior to Verify command Each command shall contain the correct syntax and be issued at the
Pass Criteria:

Page 44

appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL) Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. Get Data For PIN Try Counter: If Terminal Supports 80 CA 9F 17 00 Lc = Not Present Command Data = Not Present Get Challenge: Mandatory Command if terminal supports Enciphered Pin 00 84 00 00 Lc Command Data Le Lc = Not Present Command Data = Not Present Le = 00 Verify: Mandatory Command if terminal supports Enciphered Pin 00 20 00 P2 Lc Command Data Le P2 = Qualifier (88 enciphered) Command Data (Transaction Pin Data) Le = (Not Present) Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 45
2CS.006.00 Get Data

Test No. 2CS.006.00 Objective: To ensure that if the terminal supports Velocity Checking as a part of Terminal Risk
Management, the terminal shall issue the Get Data command in the correct format and is issued at the expected times during the transaction flow.
Reference: 2RA.043.0 - Book 3 Section 2.5.7.2 - Syntax of GET DATA command 2RA.043.5 - Book 3 Section 2.5.7.2 - Syntax of GET DATA command Data Field Conditions:
ICC contains AIP value 08 00 Terminal Risk Management to be performed ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) ICC contains Upper and Lower Consecutive Off-line Limits All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
Procedure:
For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Terminal Risk Management Terminal Action Analysis Completion. Terminal shall process the card to completion for all the EMV transactions. Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. Terminal shall issue Get Data Commands for Application Transaction Counter and Last On-line Application Transaction Counter after Read st Application Data but prior to 1 GEN AC. Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0) Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL)
Pass Criteria:
Page 46

Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. Get Data For ATC: Mandatory Command 80 CA 9F 36 00 Lc = Not Present Command Data = Not Present Get Data For Last Online ATC: Mandatory Command 80 CA 9F 13 00 Lc = Not Present Command Data = Not Present Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 47
2CS.007.00 External Authenticate

Test No. 2CS.007.00 Objective: To ensure that a terminal with online capability can issue the External Authenticate
command after the first Generate AC but prior to second Generate AC. The command is in the correct format and issued at the expected times during the transaction flow.
Reference: 2RA.036.0 - Book 3 Section AUTHENTICATE command
2.5.4.2
Syntax Syntax
of of
EXTERNAL EXTERNAL
2RA.037.0 - Book 3 Section 2.5.4.3 AUTHENTICATE command Data Field Conditions:

ICC contains AIP value 04 00 Issuer authentication is supported ICC contains the following mandatory Data Objects (Application Expiration Date, Application PAN, CDOL1, and CDOL2) Terminal online capability 1 GEN AC ARQC Issuer authentication data- returned in response to host All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'
st
Procedure:
For Generate AC Command P1=40 The terminal will perform the following functions as a part of the basic EMV transaction: Application Selection Initiate Application Processing Read Application Data Terminal Action Analysis Online Processing Issuer Authentication Completion. Terminal shall process the card to completion for all the EMV transactions. Terminal shall be consistent with the command formats. Terminal shall issue all mandatory commands as specified below. Terminal shall issue External Authenticate command after the First Generate AC command, but prior to the Second Generate AC command. Each command shall contain the correct syntax and be issued at the appropriate time. (Follow command flow and syntax below)
Select: Mandatory Command 00 A4 04 00 Lc Command Data Le Lc = 05 10 (Length of Command Data) Command Data = File Name Le = (Not Present T=0)
Pass Criteria:

Page 48

Get Processing Options: Mandatory Command 80 A8 00 00 Lc Command Data Le Lc = variable (Length of Command Data) Command Data = (Processing Options Data Object List - PDOL) Le = (Not Present T=0) Read Record: Mandatory Command 00 B2 P1 P2 00 P1 = Record Number P2= Reference control parameter Short File Indicator (SFI) Multiple Read Record commands will be issued dependent on Application File Locators. First Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Note: For this test P1 = 80. Le = 00 (Not Present T=0) External Authenticate: Mandatory Command 00 82 00 00 Lc Command Data Le Lc = 8 16 (Length of Command Data) Command Data = Issuer Authentication Data Le = Not Present Second Generate AC: Mandatory Command 80 AE P1 00 Lc Command Data Le P1 = Reference Control Parameter (00 AAC, 40 TC, 80 ARQC) Le = 00 (Not Present T=0)
Page 49
ICC Specification for Payment System, Test Case Description

Book 3 Part 1 - Data Element and Commands
2CA.001.03
Test No. 2CA.001.03 Objective: To ensure that the retrieved values fields of the data elements are stored in the terminal buffer for possible later use in the application. Reference: 2RA.001.3 - Book 3 Section 1.2 - Data elements Storage Conditions: The terminal receive and store data element sent by the LT The data sent by the LT are set up so that the transaction will be approved
Data elements Storage
Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall complete and approve the transaction The data in the terminal buffer when sent in the batch data capture shall be in accordance with values sent back by the LT
Page 50
2CA.001.00
Test No. 2CA.001.00
Coding and Allocation of Tags
Objective: To ensure that the terminal complies with the Data Object coding and allocation scheme as described in ISO/IEC 7816-6 and Book 3 Annex B. Reference: 2RA.001.0 - Book 3 Section 1.2 & Book 3 Annex B - Coding and Allocation of Tags Conditions: LT is such as all types of Data Objects are exchanged during the transaction: All templates, Data Objects with tag on 1,2, bytes, Data Objects with length on 1, 0r 2, or 3 bytes, Constructed Data Objects Primitive Data Objects All Data Objects received from Terminal shall be in accordance with ISO/IEC 7816-6 coding Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: Data Object received by the Terminal shall be interpreted correctly
Page 51
2CA.001.04
Test No. 2CA.001.04
Coding of Length in TLV
Objective: To ensure that the terminal is capable of correctly interpreting TLV data objects with a length field coded 00 as defined in ISO/IEC 7816. A data element with length 00 is treated as not present. Reference: 2RA.001.4 - Book 3 Section 1.2 Coding of Length in TLV Conditions: The LT send a data object with a length field coded '00'
Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall treat this data as not present and complete transaction
2CA.002.00 Mapping of data objects into records

Test No. 2CA.002.00 Objective: To ensure that the terminal accepts any mapping of data object into records . Reference: 2RA.001.1 - Book 3 Section 1.2 - Mapping of data objects into records Conditions: Data object of LT are mapped into different records organization (and AFL is in accordance) (for instance Track2 Equivalent Data can be located in file with any SFI value) Data objects of LT are ordered differently within records (for instance mandatory data object Expiration Date, PAN, CDOL1 and CDOL2 can be ordered differently) Procedure: Read Application Data phase is performed with the LT for all conditions above Pass Criteria: The terminal shall perform Read Application Data phase correctly and process the transaction until the end. Data objects shall be stored with the good value in the terminal (whenever it is possible to have access to their value)
Page 52
2CA.004.00 Retrieval of DIR file

Test No. 2CA.004.00 Objective: To ensure that if the terminal supports selection with PSE, it accepts any value in the range of 1 to 10 for the SFI of the directory file. Reference: 2RA.003.0 - Book 1 Section 6.1.4 - Retrieval of DIR file Conditions: Terminal supports selection with PSE SFI of Directory is coded with different values in the range of 1 to 10 for the FCI of PSE of LT Procedure: Application Selection with PSE phase is performed with LT for all conditions Pass Criteria: The LT shall receive a READ RECORD command for all values of SFI tested
2CA.007.00 Processing Options Data Object List (PDOL)

Test No. 2CA.007.00 Objective: To ensure that the terminal supports valid PDOL. Reference: 2RA.006.0 - Book 3 Section 1.4 - Processing Options Data Object List (PDOL) Conditions: FCI of Application in LT contains a valid PDOL Procedure: Application in LT is selected and Initiate Application phase is performed with LT Pass Criteria: The terminal shall return a GET PROCESSING OPTION command to the LT with PDOL field correctly filled
Page 53
2CA.008.00 Card Risk management Data Object List 1 (CDOL1)

Test No. 2CA.008.00 Objective: To ensure that the terminal supports valid CDOL1. Reference: 2RA.006.1 - Book 3 Section 1.4 - Card Risk management Data Object List 1 (CDOL1) Conditions: Application data in LT contains a valid CDOL1 Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with CDOL1 field correctly filled
2CA.009.00 Card Risk management Data Object List 2 (CDOL2)

Test No. 2CA.009.00 Objective: To ensure that the terminal supports valid CDOL2 Reference: 2RA.006.2 - Book 3 Section 1.4 - Card Risk management Data Object List 2 (CDOL2) Conditions: Application data in LT contains a valid CDOL2. Terminal parameters is set so that transaction is performed on-line Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall return a 2nd GENERATE AC command to the LT with CDOL2 field correctly filled
Page 54
2CA.010.00 Transaction Data Object List (TDOL)

Test No. 2CA.010.00 Objective: To ensure that the terminal supports valid TDOL. Reference: 2RA.006.3 - Book 3 Section 1.4 - Transaction Data Object List (TDOL) Conditions: Application data in LT contains a valid TDOL Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with TC Hash Value calculated with correct inputs
2CA.011.00 Dynamic Data Object List (DDOL)

Test No. 2CA.011.00 Objective: To ensure that the terminal supports valid DDOL. Reference: 2RA.006.4 - Book 3 Section 1.4 - Dynamic Data Object List (DDOL) Conditions: Application data in LT contains a valid DDOL Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall return an INTERNAL AUTH command to the LT with DDOL field correctly filled
Page 55
2CA.013.00 Processing DOLs: unknown tag

Test No. 2CA.013.00 Objective: To verify that whenever the tag of any data object identified in the DOL is unknown to the terminal, the IUT provides a data element with the length specified and a value of all hexadecimal zeroes. Reference: 2RA.008.0 - Book 3 Section 1.4 - Processing DOLs: unknown tag Conditions: The LT has previously sent the DOL to the terminal. The DOL contains the tag of a Data Object which is unknown to the terminal. Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL).
2CA.014.00 Processing DOLs: constructed tag

Test No. 2CA.014.00 Objective: To verify that whenever the tag of any data object identified in the DOL represents a constructed data object, the IUT provides a data element with the length specified and a value of all hexadecimal zeroes. Reference: 2RA.008.1 - Book 3 Section 1.4 - Processing DOLs: constructed tag Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a tag representing a constructed Data Object. Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL).
Page 56
2CA.015.00 Processing DOLs: data absent from ICC

Test No. 2CA.015.00 Objective: To verify that whenever a data object is in the list and is meaningful to the IUT but represents optional static data absent from the ICC, the portion of the command field corresponding is filled with hexadecimal zeroes Reference: 2RA.009.0 - Book 3 Section 1.4 - Processing DOLs: data absent from ICC Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a Data Object representing static data that is absent from the ICC Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL).
2CA.016.00 Processing DOLs: shorter data object length, numeric format

Test No. 2CA.016.00 Objective: To verify that whenever the length specified in the DOL entry is less than the length of the actual data object, leftmost bytes of the data element are truncated if the data object has numeric format. Reference: 2RA.010.0 - Book 3 Section 1.4 - Processing DOLs: shorter data object length, numeric format Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which has numeric format and a length shorter than actual Data Object Length Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly truncated (portion has the same length as the Data Object in DOL).
Page 57
2CA.017.00 Processing DOLs: shorter data object length, other format

Test No. 2CA.017.00 Objective: To verify that whenever the length specified in the DOL entry is less than the length of the actual data object, rightmost bytes of the data element are truncated if the data object has any other format than numeric. Reference: 2RA.010.1 - Book 3 Section 1.4 - Processing DOLs: shorter data object length, other format Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which has a format other than numeric and a length shorter than actual Data Object Length Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly truncated (portion has the same length as the Data Object in DOL).
Page 58
2CA.018.00 Processing DOLs: longer data object length, numeric format

Test No. 2CA.018.00 Objective: To verify that whenever the length specified in the DOL entry is greater than the length of the actual data object, the actual data is padded with leading hexadecimal zeroes if the data object has numeric format. Reference: 2RA.011.0 - Book 3 Section 1.4 - Processing DOLs: longer data object length, numeric format Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which has numeric format and a length longer than actual Data Object Length Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with leading hexadecimal zeroes (portion has the same length as the Data Object in DOL).
Page 59
2CA.019.00 Processing DOLs: longer data object length, compressed numeric format
Test No. 2CA.019.00 Objective: To verify that whenever the length specified in the DOL entry is greater than the length of the actual data object, the actual data is padded with trailing hexadecimal FFs if the data has a compressed numeric format. Reference: 2RA.011.1 - Book 3 Section 1.4 - Processing DOLs: longer data object length, compressed numeric format Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which has compressed numeric format and a length longer than actual Data Object Length Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with trailing hexadecimal FFs (portion has the same length as the Data Object in DOL).
Page 60
2CA.020.00 Processing DOLs: longer data object length, other format

Test No. 2CA.020.00 Objective: To verify that whenever the length specified in the DOL entry is greater than the length of the actual data object, the actual data is padded with trailing hexadecimal zeroes for any other format than numeric or compressed numeric. Reference: 2RA.011.2 - Book 3 Section 1.4 - Processing DOLs: longer data object length, other format Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which has a format other than numeric or compressed numeric and a length longer than actual Data Object Length Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object correctly padded with trailing hexadecimal zeroes (portion has the same length as the Data Object in DOL).
Page 61
2CA.021.00 Processing DOLs: data not applicable

Test No. 2CA.021.00 Objective: To verify that whenever a data object is in the list and is meaningful to the IUT but is not applicable to the current transaction, the portion of the command field corresponding is filled with hexadecimal zeroes Reference: 2RA.012.0 - Book 3 Section 1.4 - Processing DOLs: data not applicable Conditions: The LT has previously sent the DOL to the terminal. The DOL contains a data object which represents data that is not applicable to the current transaction Procedure: Application in LT is selected and transaction is performed with LT (in particular the DOL processing). Pass Criteria: The LT shall receive the DOL with portion of the DOL field representing the Data Object filled with hexadecimal zeroes (portion has the same length as the Data Object in DOL).
Page 62
2CA.025.00 Normal Processing for EXTERNAL AUTHENTICATE

Test No. 2CA.025.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to EXTERNAL AUTHENTICATE command and understands it as normal processing Reference: 2RA.018.0 - Book 3 Section 2.3.5 - Normal Processing for External Authenticate Conditions: Terminal and LT parameters are set so that transaction is performed online. AIP of LT is set so that Issuer Authentication is supported. Issuer Authentication Data is sent back to the terminal in the emulated response from Issuer. LT shall return status 90 AUTHENTICATE command. CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular on-line processing and Issuer Authentication processing) . Pass Criteria: The terminal shall process the transaction until completion. TVR byte 5, bit 7 = 0 ie Issuer Authentication Successful TSI byte 1, bit 5=1 ie Issuer authentication was performed. 00 in response to EXTERNAL
Page 63
2CA.026.00 Failed Processing for EXTERNAL AUTHENTICATE

Test No. 2CA.026.00 Objective: To ensure that the terminal accepts a failed status 63 00 in response to EXTERNAL AUTHENTICATE command and understands it as failed processing Reference: 2RA.018.1 - Book 3 Section 4.1 - Failed processing for External Authenticate (1) Conditions: Terminal and LT parameters are set so that transaction is performed online. AIP of LT is set so that Issuer Authentication is supported. Issuer Authentication Data is sent back to the terminal in the emulated response from Issuer. LT returns status 63 00 in response to EXTERNAL AUTHENTICATE CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular on-line processing and Issuer Authentication processing). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 5, bit 7 = 1 ie Issuer Authentication Unsuccessful TSI byte 1, bit 5=1 ie Issuer authentication was performed
Page 64
2CA.027.00 Normal Processing for GENERATE AC

Test No. 2CA.027.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to GENERATE AC command and understands it as normal processing Reference: 2RA.019.0 - Book 3 Section 2.3.5 - Normal Processing for Generate AC Conditions: LT returns status 90 00 in response to GENERATE AC as well as a valid response Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion.
2CA.028.00 Normal Processing for GET CHALLENGE

Test No. 2CA.028.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to GET CHALLENGE command and understands it as normal processing Reference: 2RA.020.0 - Book 3 Section 2.3.5 - Normal Processing for Get Challenge Conditions: Terminal supports Enciphered offline PIN verification LT returns status 90 00 in response to GET CHALLENGE as well as a valid response CVM is 'Enciphered offline PIN verification, always' PIN entered is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1, bit 7 =1 Cardholder Verification was performed
Page 65
2CA.029.00 Normal Processing for GET DATA

Test No. 2CA.029.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to GET DATA command and understands it as normal processing Reference: 2RA.021.0 - Book 3 Section 2.3.5 - Normal Processing for Get Data Conditions: Terminal supports Terminal Risk Management (AIP byte 1 bit 4 = 1). LT contains Lower and Upper consecutive offline limits (for ATC and LOATC retrieval). LT returns status 90 00 in response to GET DATA as well as a valid response CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 0 ie ICC Data not missing
Page 66
2CA.029.05 Failed Processing for GET DATA (1)

Test No. 2CA.029.05 Objective: To ensure that the terminal accepts a failed status 6A81 or '6A 88' in response to GET DATA command and understands it as failed processing when Terminal Velocity Checking is performed. Reference: 2RA.021.1 - Book 3 Section 2.3.5 - Failed Processing for Get Data (1) Conditions: Terminal supports Terminal Risk Management LT supports Terminal Risk Management (AIP byte 1 bit 4 = 1) LT returns tags 9F 14 and 9F 23 during Read Application Data LT returns status 6A81 or '6A88' in response to GET DATA command. CDOL1 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 6 =1 i.e. ICC data missing TVR byte 4, bit 7 =1 i.e. Lower consecutive offline limit exceeded TVR byte 4, bit 6= 1 i.e. Upper consecutive offline limit exceeded
Page 67
2CA.029.06 Failed Processing for GET DATA (2)

Test No. 2CA.029.06 Objective: To ensure that the terminal accepts a failed status 6A81 or '6A 88' in response to GET DATA command and understands it as failed processing and proceeds with PIN Verification processing. Reference: 2RA.021.2 - Book 3 Section 2.3.5 - Failed Processing for Get Data (2) Conditions: Terminal support Offline PIN processing (Enciphered or Plaintext) Terminal supports GET DATA for PIN Try Counter LT supports Cardholder Verification (AIP byte 1 bit 5 = 1) CVM List requests 'Enciphered PIN, if terminal supports' followed by 'Plaintext PIN, if terminal supports' LT returns status 6A81 or '6A88' in response to GET DATA command. CDOL1 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion The terminal performs PIN processing
Page 68
2CA.030.00 Normal Processing for GET PROCESSING OPTIONS

Test No. 2CA.030.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to GET PROCESSING OPTIONS command and understands it as normal processing Reference: 2RA.022.0 - Book 3 Section 2.3.5 - Normal Processing for Get Processing Options Conditions: LT returns status 90 00 in response to GET PROCESSING OPTIONS as well as a valid response
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion.
2CA.030.05 Failed Processing for GET PROCESSING OPTIONS

Test No. 2CA.030.05 Objective: To ensure that the terminal accepts a failed status 6985 in response to GET PROCESSING OPTIONS command and understands it as failed processing. Reference: 2RA.022.5 - Book 3 Section 2.3.5 & Section 6.1 - Failed Processing for Get Processing Options Conditions: The LT and the terminal have two mutually supported applications LT returns status 6985 in response to GET PROCESSING OPTIONS of the first selected application
Procedure: The first application in the candidate list in selected, then removed and the terminal initiate the selection of the second mutually supported application. Pass Criteria: In response to the status words 6985, the terminal shall terminate processing the current application and return to the application selection function to select another application
Page 69
2CA.031.00 Normal Processing for Internal Authenticate

Test No. 2CA.031.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to INTERNAL AUTHENTICATE command and understands it as normal processing Reference: 2RA.023.0 - Book 3 Section 2.3.5 - Normal Processing for Internal Authenticate Conditions: LT and terminal support DDA. LT returns status 90 00 in response to INTERNAL AUTHENTICATE as well as a valid response CDOL1 request TVR and TSI
Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication not failed TSI byte 1, bit 8=1 ie Offline data authentication was performed
2CA.032.00 Normal Processing for READ RECORD

Test No. 2CA.032.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to READ RECORD command and understands it as normal processing Reference: 2RA.024.0 - Book 3 Section 2.3.5 - Normal Processing for Read Record Conditions: LT returns status 90 00 in response to READ RECORD as well as a valid response
Procedure: Application in LT is selected and transaction is processed with LT (in particular the Read Application Data phase). Pass Criteria: The terminal shall process the transaction until completion.
Page 70
2CA.032.05 Failed Processing for READ RECORD

Test No. 2CA.032.05 Objective: To ensure that the terminal accepts a failed status 6A 83 in response to READ RECORD command and understands it as failed processing. Reference: 2RA.024.1 - Book 1 Section 8.3.2 - Failed Processing for Read Record Conditions: The terminal supports selection with PSE LT returns status 6A83 in response to READ RECORD for record number 1 in application selection using PSE
Procedure: The first application in the candidate list in selected, then removed and the terminal initiate the selection of the second mutually supported application. Pass Criteria: In response to the status words 6A83, the terminal shall terminate PSE processing and return to the application selection function using the list of AID
2CA.033.00 Normal Processing for Select

Test No. 2CA.033.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to SELECT command and understands it as normal processing Reference: 2RA.025.0 - Book 3 Section 2.3.5 - Normal Processing for Select Conditions: LT returns status 90 00 in response to SELECT as well as a valid response
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion.
Page 71
2CA.034.00 Normal Processing for VERIFY

Test No. 2CA.034.00 Objective: To ensure that the terminal accepts a valid status 90 00 in response to VERIFY command and understands it as normal processing. Reference: 2RA.026.0 - Book 3 Section 2.3.5 - Normal Processing for Verify Conditions: Terminal and LT support Offline PIN Verification. LT returns status 90 00 in response to VERIFY. CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification).
Pass Criteria: The terminal shall process the transaction until completion. TVR byte 3, bit 6 = 0 ie PIN Try limit not exceeded TVR byte 3, bit 5 = 0 ie PIN Entry required and PIN pad present TVR byte 3, bit 4 = 0 ie PIN entered TSI byte 1, bit 7=1 ie Cardholder verification was performed
Page 72
2CA.034.02 Failed Processing for VERIFY (1)

Test No. 2CA.034.02 Objective: To ensure that the terminal accepts a status 63 Cx in response to VERIFY command and understands it as counter provided by 'x'. Reference: 2RA.026.2 - Book 3 Section 2.3.5 - Failed Processing for Verify (1) Conditions: The terminal supports Plaintext PIN verification by ICC or Enciphered PIN verification performed by ICC CVM List is 'Plaintext PIN verification by ICC' (byte 9 bits 6-1 = 000001) or 'Enciphered PIN verification performed by ICC' (byte 9 bits 6-1 = 000100) or 'Plaintext PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000011) or 'Enciphered PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000101) LT supports Cardholder Verification (AIP byte 1 bit 5 = 1) The operator enters a wrong PIN LT returns status 63C2" then "63C1" then "63C0" in response to the Verify Commands
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal understands there is no more PIN try left and stops sending verify commands. TVR byte 3, bit 6=1 ie PIN Try Limited exceeded TSI byte 1, bit 7=1 ie Cardholder verification was performed
Page 73

Test No. 2CA.034.03 Objective: To ensure that the terminal accepts a failed status 69 83 in response to VERIFY command and understands it as failed processing. Reference: 2RA.026.3 - Book 3 Section 2.3.5 - Failed Processing for Verify (2) Conditions: The terminal supports Plaintext PIN verification by ICC or Enciphered PIN verification performed by ICC CVM List is 'Plaintext PIN verification by ICC' (byte 9 bits 6-1 = 000001) or 'Enciphered PIN verification performed by ICC' (byte 9 bits 6-1 = 000100) or 'Plaintext PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000011) or 'Enciphered PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000101) LT supports Cardholder Verification (AIP byte 1 bit 5 = 1) LT returns status 6983" in response to the Verify Command CDOL1 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 3, bit 6 = 1 ie PIN Try limit exceeded
Page 74

Test No. 2CA.034.04 Objective: To ensure that the terminal accepts a failed status 69 84 in response to VERIFY command and understands it as failed processing. Reference: 2RA.026.4 - Book 3 Section 2.3.5 - Failed Processing for Verify (3) Conditions: The terminal supports Plaintext PIN verification by ICC or Enciphered PIN verification performed by ICC CVM List is 'Plaintext PIN verification by ICC' (byte 9 bits 6-1 = 000001) or 'Enciphered PIN verification performed by ICC' (byte 9 bits 6-1 = 000100) or 'Plaintext PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000011) or 'Enciphered PIN verification performed by ICC and signature' (byte 9 bits 6-1 = 000101) LT supports Cardholder Verification (AIP byte 1 bit 5 = 1) LT returns status 6984" in response to the Verify Command CDOL1 requests TVR and TSI
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 3, bit 6 = 1 ie PIN Try limit exceeded
Page 75
2CA.035.00 Status Word Processing for GENERATE AC

Test No. 2CA.035.00 Objective: To ensure that the terminal rejects transaction if status in response to GENERATE AC command is different from 90 00. Reference: 2RA.027.1 - Book 3 Section 2.3.5 - Status Word Processing: Generate AC Conditions: LT return several status values different from 90 00 in response to GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall terminate processing of transaction.
2CA.036.00 Status Word Processing for GET CHALLENGE

Test No. 2CA.036.00 Objective: To ensure that the terminal rejects transaction if status in response to GET CHALLENGE command is different from 90 00. Reference: 2RA.027.2 - Book 3 Section Challenge 2.3.5 - Status Word Processing: Get
Conditions: Terminal supports Enciphered offline PIN verification LT returns status different from 90 00 in response to GET CHALLENGE CVM is 'Enciphered offline PIN verification, always' Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall terminate processing of transaction
Page 76
2CA.037.00 Status Word Processing for GET PROCESSING OPTIONS

Test No. 2CA.037.00 Objective: To ensure that the terminal rejects transaction if status in response to GET PROCESSING OPTIONS command is different from 90 00 and 69 85. Reference: 2RA.027.4 - Book 3 Section Processing Options Conditions: 2.3.5 - Status Word Processing: Get
LT returns several status values different from 90 00 and 69 85 in response to GET PROCESSING OPTIONS.
Procedure: Application in LT is selected and transaction is started with LT. Pass Criteria: The terminal shall terminate processing of transaction.
2CA.039.00 Status Word Processing for READ RECORD

Test No. 2CA.039.00 Objective: To ensure that the terminal rejects transaction if status in response to READ RECORD command sent outside application selection is different from 90 00 and 6A 83. Reference: 2RA.027.6 - Book 3 Section 2.3.5 - Status Word Processing: Read Record Conditions: LT returns several status values different from 90 00 and 6A 83 in response to READ RECORD during the Read Application Data phase.
Procedure: Application in LT is selected and transaction is processed with LT up to the Read Application Data phase. Pass Criteria: The terminal shall terminate processing of transaction.
Page 77
2CA.040.00 Status Word Processing for VERIFY

Test No. 2CA.040.00 Objective: To ensure that the terminal rejects transaction if status in response to VERIFY command is different from 90 00 and 63 Cx 69 83 and 69 84. Reference: 2RA.027.8 - Book 3 Section 2.3.5 - Status Word Processing: Verify Conditions: Terminal and LT shall support Offline PIN Verification. LT shall return several status values different from 90 00 and 63 Cx 69 83 and 69 84 in response to VERIFY. Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall terminate processing of transaction.
2CA.041.00 Coding of Bits and Bytes RFU

Test No. 2CA.041.00 Objective: To allow for migration and support of new functionality, the IC Card and the terminal shall not verify the data indicated as RFU. Reference: 2RA.030.5 - Book 3 Section 2.3.6 - Coding of Bits and Bytes RFU Conditions: Data send by LT have some RFU bit set to 1b (Application Interchange Profile, Application Usage Control, CVM list, Application Priority Indicator, Issuer Action Code, Terminal Action Code) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall not verify RFU bits and complete transaction
Page 78
2CA.054.00 Syntax of GENERATE AC returned Data Field (Format 1)

Test No. 2CA.054.00 Objective: To ensure that the terminal is able to recognize the GENERATE AC returned Data field encoded according to format 1 syntax and in particular the order of the value field of Data Object included in the returned Data field. Reference: 2RA.040.0 - Book 3 Section 2.5.5.4 - Syntax of GENERATE AC returned Data Field (Format 1) Conditions: Response to GENERATE AC includes Issuer Application Data and shall be encoded with format 1 (Template 80) Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and interprete correctly the format 1 syntax. The terminal shall process the transaction until the end. Values for Cryptogram Information Data, ATC, Application Cryptogram, Issuer Application Data managed by the terminal and included in authorization or financial requests or batch data capture shall be in accordance with values sent back by the LT
Page 79
2CA.055.00 Syntax of GENERATE AC returned Data Field (Format 2)

Test No. 2CA.055.00 Objective: To ensure that the terminal is able to recognize the GENERATE AC returned Data field encoded according to format 2 syntax. Reference: 2RA.041.0 - Book 3 Section 2.5.5.4 - Syntax of GENERATE AC returned Data Field (Format 2) Conditions: Response to GENERATE AC includes Issuer Application Data and shall be encoded with format 2 (Template 77) Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and interprete correctly the format 2 syntax. The terminal shall run the transaction to completion according to the LTs response to the GENERATE AC command.
2CA.056.00 Proprietary Data Object transmitted in Response to GENERATE AC: Format 2

Test No. 2CA.056.00 Objective: To ensure that the terminal ignores proprietary data object contained in the response to the GENERATE AC command when response has format 2. Reference: 2RA.041.1 - Book 3 Section 2.5.5.4 - Proprietary Data Object transmitted in Response to GENERATE AC: Format 2 (implied) Conditions: Response to GENERATE AC includes Proprietary Data Object and shall be encoded with format 2 (Template 77) Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and ignore the format 2 proprietary data object in the response to the GENERATE AC command. The terminal shall process the transaction until the end.
Page 80
2CA.057.00 Cryptogram Information Data

Test No. 2CA.057.00 Objective: To ensure that the terminal accepts the presence of a valid Cryptogram Information Data in response to the GENERATE AC command. Reference: 2RA.042.0 - Book 3 Section 2.5.5.4 - Cryptogram Information Data Conditions: Cryptogram Information Data is coded according to Table I-14 Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The terminal shall act in the appropriate manner for the returned Cryptogram Information Data (i.e. Terminal requests TC and ICC returns TC, the transaction is approved) .
2CA.058.00 Application Transaction Counter

Test No. 2CA.058.00 Objective: To ensure that the terminal accepts the presence of a valid format of Application Transaction Counter in response to the GENERATE AC command. Reference: 2RA.042.1 - Book 3 Section 2.5.5.4 - Application Transaction Counter Conditions: CDOL2 requests Application Transaction Counter LT requests ARQC to First GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The terminal will return the correct value of the ATC during Second GENERATE AC as returned by the LT during First GENERATE AC.
Page 81
2CA.059.00 Application Cryptogram

Test No. 2CA.059.00 Objective: To ensure that the terminal accepts the presence of a valid format of Application Cryptogram in response to the GENERATE AC command. Reference: 2RA.042.2 - Book 3 Section 2.5.5.4 - Application Cryptogram Conditions: Application Cryptogram can be a live data or test data CDOL2 requests Application Cryptogram LT requests ARQC to First GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The terminal will return the correct value of the Application Cryptogram during Second GENERATE AC as returned by the LT during First GENERATE AC
Page 82
2CA.060.00 Issuer Application Data

Test No. 2CA.060.00 Objective: To ensure that the terminal accepts the presence of a valid format of Issuer Application Data in response to the GENERATE AC command. Reference: 2RA.042.3 - Book 3 Section 2.5.5.4 - Issuer Application Data Conditions: Response to GENERATE AC includes Issuer Application Data CDOL2 requests Issuer Application Data LT requests ARQC to First GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The terminal will return the correct value of the Issuer Application Data during Second GENERATE AC as returned by the LT during First GENERATE AC
2CA.061.00 Cryptogram Information Data: AAC

Test No. 2CA.061.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requesting the ICC to return an AAC. Reference: 2RA.042.4 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: AAC Conditions: The LT requests an AAC in response to the first GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall decline the transaction
Page 83
2CA.062.00 Cryptogram Information Data: TC

Test No. 2CA.062.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requesting the ICC to return a TC. Reference: 2RA.042.5 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: TC Conditions: The terminal and LT request a TC in response to the first GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall approve the transaction offline
2CA.063.00 Cryptogram Information Data: ARQC

Test No. 2CA.063.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requesting the ICC to return an ARQC. Reference: 2RA.042.6 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: ARQC Conditions: The terminal and LT request an ARQC in response to the first GENERATE AC Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall complete the transaction on line
Page 84
2CA.064.00 Cryptogram Information Data: AAR

Test No. 2CA.064.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requesting the ICC to return an AAR. Reference: 2RA.042.7 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: AAR Conditions: Terminal supports Referrals The LT requests an AAR in response to the first GENERATE AC
Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall ask for a referral
2CA.065.00 Cryptogram Information Data: Advice required

Test No. 2CA.065.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requiring an Advice. Reference: 2RA.042.8 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: Advice required Conditions: The LT requires an Advice in response to the first GENERATE AC. Terminal supports Advices Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall create and transmit an advice.
Page 85
2CA.066.00 Cryptogram Information Data: Service Not allowed

Test No. 2CA.066.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requiring an Advice and indicating a Service not allowed. Reference: 2RA.042.9 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: Service Not allowed Conditions: The LT requests an AAC and requires an Advice in response to the first GENERATE AC. Reason indicated by LT is service not allowed. Terminal supports Advices Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall either transmit an on line advice or create an offline advice. Reason for decline included in Advice shall be service not allowed
Page 86
2CA.067.00 Cryptogram Information Data: PIN try limit exceeded

Test No. 2CA.067.00 Objective: To verify that the terminal interprets correctly answer to a GENERATE AC command requiring an Advice and indicating a PIN try limit exceeded. Reference: 2RA.042.10 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: PIN try limit exceeded Conditions: The LT requests an AAC and requires an Advice in response to the first GENERATE AC. Reason indicated by LT is PIN try limit exceeded. Terminal supports Advices Procedure: Application in LT is selected and transaction is performed with LT until completion Pass Criteria: The terminal shall either transmit an on line advice or create an offline advice. Reason for decline included in Advice shall be PIN try limit exceeded
Page 87
2CA.070.00 Syntax of GET DATA returned Data Field (ATC)

Test No. 2CA.070.00 Objective: To ensure that the terminal is able to recognize the GET DATA returned Data field when ATC is requested Reference: 2RA.044.0 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned Data Field (ATC) Conditions: Terminal supports Terminal Risk Management LT requesting terminal to perform risk management (AIP byte 1 bit 4 = 1). LT contains Lower and Upper consecutive offline limits (for ATC retrieval). LT returns status 90 00 in response to GET DATA as well as a valid response (ATC) CDOL1 Requests TVR and TSI Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end TVR byte 1, bit 6 = 0 ie ICC Data not Missing TSI Byte 1, bit 4=1 ie Terminal risk Management was performed
Page 88
2CA.071.00 Syntax of GET DATA returned Data Field (LOATC)

Test No. 2CA.071.00 Objective: To ensure that the terminal is able to recognize the GET DATA returned Data field when LOATC is requested Reference: 2RA.044.1 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned Data Field (LOATC) Conditions: Terminal supports Terminal Risk Management LT requesting terminal to perform risk management (AIP byte 1 bit 4 = 1). LT contains Lower and Upper consecutive offline limits (for LOATC retrieval). LT returns status 90 00 in response to GET DATA as well as a valid response (LOATC) CDOL1 Requests TVR and TSI Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end TVR byte 1, bit 6 = 0 ie ICC Data not Missing TSI Byte 1, bit 4=1 ie Terminal risk Management was performed
Page 89
2CA.072.00 Syntax of GET DATA returned Data Field (PIN try limit)
Test No. 2CA.072.00 Objective: To ensure that the terminal is able to recognize the GET DATA returned Data field when PIN try limit is requested Reference: 2RA.044.2 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned Data Field (PIN try counter) Conditions: LT supports Cardholder Verification (AIP byte 1 bit 5 = 1)
Terminal support GET DATA for PTC CVM List is 'Plaintext PIN verification by ICC' (byte 9 bits 6-1 = 000001) or 'Enciphered PIN verification by ICC' (byte 9 bits 6-1 = 000100) or 'Plaintext PIN verification by ICC and signature' (byte 9 bits 6-1 = 000011) or 'Enciphered PIN verification by ICC and signature' (byte 9 bits 6-1 = 000101) PIN try counter = 0 LT returns status 90 00 in response to GET DATA as well as a valid response (PIN try Counter) CDOL1 Requests TVR and TSI Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. TVR byte 3, bit 6 = 1 ie PIN Try limit exceeded TSI Byte 1, bit 7=1 ie, Cardholder verification was performed
Page 90
2CA.074.00 Syntax of GET PROCESSING OPTIONS Data Field (PDOL)

Test No. 2CA.074.00 Objective: To ensure that the terminal issues a GET PROCESSING OPTIONS command with a Processing Options Data Object List (PDOL) when PDOL data object is present in the FCI of the Application Definition File. Reference: 2RA.046.0 - Book 3 Section 2.5.8.3 - Syntax of GET PROCESSING OPTIONS Data Field (PDOL) Conditions: PDOL is returned in the FCI of the selected ADF Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a GET PROCESSING OPTIONS data field (associated to the GET PROCESSING OPTIONS command field) with the correct syntax: data object containing value fields of Data Object requested introduced by Tag 83
2CA.075.00 Syntax of GET PROCESSING OPTIONS Data Field (no PDOL)

Test No. 2CA.075.00 Objective: To ensure that the terminal issues a GET PROCESSING OPTIONS command without a Processing Options Data Object List (PDOL) when the PDOL data object is not present in the FCI of the selected ADF Reference: 2RA.047.0 - Book 3 Section 2.5.8.3 - Syntax of GET PROCESSING Data Field (no PDOL) Conditions: PDOL is not returned in the FCI of the selected ADF Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a GET PROCESSING OPTIONS data field (associated to the GET PROCESSING OPTIONS command field) with the correct syntax: data object with length = 0 and Tag 83
Page 91
2CA.076.00 Syntax of GET PROCESSING OPTIONS Data Field: PDOL empty (implied)
Test No. 2CA.076.00 Objective: To ensure that the terminal issues a GET PROCESSING OPTIONS command without a Processing Options Data Object List (PDOL) when the PDOL data object is present in the FCI of the selected ADF but is empty Reference: 2RA.047.1 - Book 3 Section 2.5.8.3 - Syntax of GET PROCESSING OPTIONS Data Field: PDOL empty (implied) Conditions: PDOL is returned in the FCI of the selected ADF and is empty Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a GET PROCESSING OPTIONS data field (associated to the GET PROCESSING OPTIONS command field) with the correct syntax: data object with length = 0 and Tag 83
Page 92
2CA.077.00 Syntax of GPO returned Data Field: Format 1

Test No. 2CA.077.00 Objective: To ensure that the terminal is able to recognize the GET PROCESSING OPTIONS returned Data field encoded according to format 1. Reference: 2RA.049.0 - Book 3 Section 2.5.8.3 - Syntax of GET PROCESSING OPTIONS returned Data Field: Format 1 Conditions: Response to GET PROCESSING OPTIONS contains valid AIP and AFL encoded with format 1 (Template 80) CDOL 1 requests AIP
Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. Value of AIP in GENERATE AC command shall be in accordance with the value sent back by the LT.
LT shall receive READ RECORD commands in accordance to AFL
Page 93
2CA.078.00 Syntax of GPO returned Data Field: Format 2

Test No. 2CA.078.00 Objective: To ensure that the terminal is able to recognize the GET PROCESSING OPTIONS returned Data field encoded according to format 2. Reference: 2RA.050.0 - Book 3 Section 2.5.8.4 - Syntax of GET PROCESSING OPTIONS returned Data Field: Format 2 Conditions: Response to GET PROCESSING OPTIONS contains valid AIP and AFL encoded with format 2 (Template 77) CDOL 1 requests AIP
Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. Value of AIP in GENERATE AC command shall be in accordance with the value sent back by the LT. LT shall receive READ RECORD commands in accordance to AFL
Page 94
2CA.081.00 Syntax of INTERNAL AUTHENTICATE command

Test No. 2CA.081.00 Objective: To verify that the terminal is able to transmit a good encoding of the INTERNAL AUTHENTICATE command which initiates the computation of the Signed Dynamic Application Data by the card. Reference: 2RA.053.0 - Book 3 Section AUTHENTICATE command Conditions: Terminal and LT support DDA LT contains DDOL and all data needed for Dynamic Data Authentication as defined in Book 2 Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive INTERNAL AUTHENTICATE command with the correct syntax: 00 88 00 00 xx 2.5.9.2 Syntax of INTERNAL
2CA.082.00 Syntax of INTERNAL AUTHENTICATE Data Field

Test No. 2CA.082.00 Objective: To ensure that the terminal issues an INTERNAL AUTHENTICATE command with a Dynamic Data Authentication Data Object List (DDOL) Reference: 2RA.054.0 - Book 3 Section AUTHENTICATE Data Field Conditions: Terminal and LT support DDA LT contains DDOL and all data needed for Dynamic Data Authentication as defined in Book 2 Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive an INTERNAL AUTHENTICATE data field (associated to the INTERNAL AUTHENTICATE command field) with the correct syntax: data object containing value fields of Data Object requested in DDOL 2.5.9.2 Syntax of INTERNAL
Page 95
2CA.083.00 Syntax of INTERNAL AUTHENTICATE returned Data Field: Format 1

Test No. 2CA.083.00 Objective: To ensure that the terminal is able to recognize the INTERNAL AUTHENTICATE returned Data field encoded according to format 1 Reference: 2RA.055.0 - Book 3 Section 2.5.9.4 AUTHENTICATE returned Data Field: Format 1 Conditions: Terminal and LT support DDA LT contains DDOL and all data needed for Dynamic Data Authentication as defined in Book 2 LT response to INTERNAL AUTHENTICATE shall be a correct cryptogram encoded with format 1 (template 80) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Dynamic Data Authentication succeeded Syntax of INTERNAL
Page 96
2CA.084.00 Syntax of INTERNAL AUTHENTICATE returned Data Field: Format 2

Test No. 2CA.084.00 Objective: To ensure that the terminal is able to recognize the INTERNAL AUTHENTICATE returned Data field encoded according to format 2 Reference: 2RA.056.0 - Book 3 Section 2.5.9.4 - Syntax of INTERNAL AUTHENTICATE Internal Authenticate returned Data Field: Format 2 Conditions: Terminal and LT support DDA LT contains DDOL and all data needed for Dynamic Data Authentication as defined in Book 2 LT response to INTERNAL AUTHENTICATE is a correct cryptogram encoded with format 2 (template 77) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Dynamic Data Authentication succeeded
Page 97
2CA.088.00 Syntax of READ RECORD command

Test No. 2CA.088.00 Objective: To verify that the terminal is able to transmit a good encoding of the READ RECORD command that sends transaction-related data to the ICC, which computes and returns a cryptogram Reference: 2RA.058.0 - Book 3 Section 2.5.11.2 - Syntax of READ RECORD command Conditions: AFL is not empty Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The LT shall receive an READ RECORD command with the correct syntax: 00 B2 xx xx 00
2CA.089.00 Syntax of READ RECORD returned Data Field

Test No. 2CA.089.00 Objective: To ensure that the terminal is able to recognize the READ RECORD returned Data field. Reference: 2RA.059.0 - Book 3 Section 2.5.11.4 & Book 1 Section 7.2.4 - Syntax of READ RECORD returned Data Field Conditions: AFL is not empty. CDOL1 requests PAN and Application Expiration date. All mandatory data objects are present in the LT.
Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. Values of PAN And Application Expiration date shall be in accordance of the value returned by the LT.
Page 98
2CA.092.00 Syntax of SELECT Data Field

Test No. 2CA.092.00 Objective: To verify that the terminal is able to transmit a good encoding of the SELECT data field Reference: 2RA.062.0 - Book 1 Section 7.3.3 - Syntax of SELECT Data Field Conditions: No specific conditions Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The LT shall receive a SELECT data field (associated to the SELECT command field) with the value of AID of selected application
2CA.093.00 Syntax of SELECT PSE returned Data Field

Test No. 2CA.093.00 Objective: To ensure that if the terminal supports selection with PSE, it is able to recognize the SELECT PSE returned Data field. Reference: 2RA.063.0 - Book 1 Section 7.3.4 - Syntax of SELECT PSE returned Data Field Conditions: FCI of PSE contains mandatory and optional data fields Terminal supports selection with PSE Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. LT shall received a READ RECORD command with SFI coded according to SFI returned in FCI
Page 99
2CA.094.00 Syntax of SELECT PSE returned Data Field: optional data

Test No. 2CA.094.00 Objective: To ensure that if the terminal supports selection with PSE, it accepts the absence of optional data objects in the SELECT PSE returned Data field. Reference: 2RA.063.1 - Book 1 Section 7.3.4 - Syntax of SELECT PSE returned Data Field: optional data (implied) Conditions: FCI of PSE contains mandatory but no optional data fields Terminal supports selection with PSE Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The terminal shall either propose a choice of supported languages or use the supported language if it supports only one LT shall received a READ RECORD command with SFI coded according to SFI returned in FCI
Page 100
2CA.095.00 Syntax of SELECT DDF returned Data Field

Test No. 2CA.095.00 Objective: To ensure that if the terminal supports selection with PSE, it is able to recognize the SELECT DDF returned Data field. Reference: 2RA.063.2 - Book 1 Section 7.3.4 - Syntax of SELECT DDF returned Data Field Conditions: LT contains a DDF FCI of DDF contains mandatory and optional data fields Terminal supports selection with PSE Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. LT shall received a READ RECORD command with SFI coded according to SFI returned in FCI of DDF
Page 101
2CA.096.00 Syntax of SELECT DDF returned Data Field: optional data (implied)
Test No. 2CA.096.00 Objective: To ensure that if the terminal supports selection with PSE, it accepts the absence of optional data objects in the SELECT DDF returned Data field. Reference: 2RA.063.3 - Book 1 Section 7.3.4 - Syntax of SELECT DDF returned Data Field: optional data (implied) Conditions: FCI of DDF contains mandatory but no optional data fields Terminal supports selection with PSE Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. LT shall received a READ RECORD command with SFI coded according to SFI returned in FCI of DDF
Page 102
2CA.097.00 Syntax of SELECT ADF returned Data Field

Test No. 2CA.097.00 Objective: To ensure that the terminal is able to recognize the SELECT ADF returned Data field. Reference: 2RA.063.4 - Book 1 Section 7.3.4 - Syntax of SELECT ADF returned Data Field Conditions: LT contains an ADF FCI of ADF contains mandatory and optional data fields Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. Terminal shall send a GET PROCESSING OPTIONS command with PDOL filled as specified in PDOL of FCI of ADF
2CA.098.00 Syntax of SELECT ADF returned Data Field: optional data

Test No. 2CA.098.00 Objective: To ensure that the terminal accepts the absence of optional data objects in the SELECT ADF returned Data field. Reference: 2RA.063.5 - Book 1 Section 7.3.4 - Syntax of SELECT ADF returned Data Field: optional data Conditions: LT contains an ADF FCI of ADF contains mandatory but no optional data fields Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end.
Page 103
2CA.099.00 Response to Proprietary Data in FCI

Test No. 2CA.099.00 Objective: To ensure that the terminal accepts the presence of proprietary data objects in the SELECT returned Data field. Reference: 2RA.064.0 - Book 1 Section 7.3.4 - Response to Proprietary Data in FCI Conditions: LT contains an ADF FCI of ADF contains proprietary data fields Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end.
2CA.103.00 Syntax of VERIFY Data Field for option plaintext offline PIN
Test No. 2CA.103.00 Objective: To ensure that the terminal issues a VERIFY command with a Plain Text Offline PIN Block in the data field when option is Plaintext PIN Reference: 2RA.068.0 - Book 3 Section 2.5.12.2 - Syntax of VERIFY Data Field for option plaintext offline PIN Conditions: Terminal and LT support Offline PIN Verification. Different length of PIN are tested Procedure: Application in LT is selected and transaction is performed with LT for all PIN length tested Pass Criteria: The LT shall receive a VERIFY data field (associated to the VERIFY command field) with the correct syntax as defined in Book 3 Section 2.5.12.2
Page 104
2CA.104.00 Syntax of VERIFY Data Field

Test No. 2CA.104.00 Objective: To ensure that the terminal issues a VERIFY command with value field of tag 99 in the data field Reference: 2RA.069.0 - Book 3 Section 2.5.12.3 - Syntax of VERIFY Data Field Conditions: Terminal and LT support Offline PIN Verification. Procedure: Application in LT is selected and transaction is performed with LT. Pass Criteria: The LT shall receive a VERIFY data field (associated to the VERIFY command field) with the value field of tag 99 (without Tag and Length)
2CA.108.00 Syntax of GET CHALLENGE returned Data Field

Test No. 2CA.108.00 Objective: To ensure that the terminal is able to recognize the GET CHALLENGE returned Data field. Reference: 2RA.073.0 - Book 3 Section 2.5.6.4 - Syntax of Get challenge returned Data Field Conditions: Terminal and LT support Offline enciphered PIN Verification. CVM is 'Offline enciphered PIN Verification, always' Procedure: Application in LT is selected and transaction is performed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end. The LT shall receive a VERIFY command with Data field containing, once decrypted, unpredictable number sent back by LT
Page 105
Application Selection
2CB.002.00 Definition of PSE
Test No. 2CB.002.00 Objective: To ensure that if the terminal supports selection with PSE, it understands PSE format and in particular recognize the FCI of the PSE and optional data objects Reference: 2RB.002.0 - Book 1 Section 7.3.3 - Definition of PSE Conditions: Terminal supports selection with PSE Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall accept the card. LT shall received a READ RECORD command with SFI coded according to SFI returned in FCI
Page 106
2CB.004.00 Definition of a Record in Payment Systems Directory

Test No. 2CB.004.00 Objective: To ensure that if the terminal supports selection with PSE, it understands the format of records contained in the Directory file of PSE and in particular records with several entries. Reference: 2RB.004.0 - Book 1 Section 8.2.3 - Definition of a Record in Payment Systems Directory Conditions: Terminal supports selection with PSE PSE contains a directory file with entries for ADF The first record of the directory contains several entries for ADF Procedure: Application Selection with PSE process is performed for all supported priority hierarchies. Pass Criteria: The terminal shall accept the card LT shall receive a second READ RECORD command with SFI coded according to SFI returned in FCI of the SELECT PSE command.
Page 107
2CB.005.00 Definition of Directory Entry Format

Test No. 2CB.005.00 Objective: To ensure that if the terminal supports selection with PSE, it ignores unexpected Tags that would appear in directory entry and any data objects not encapsulated in an Application Template which appear in the directory record. Reference: 2RB.005.0 - Book 1 Section 8.2.3 - Definition of Directory Entry Format Conditions: Terminal supports selection with PSE PSE contains a directory file with entries for ADF One record contains Tags that are not located in Template 61 and unexpected Tags (Tag that are not listed in Table 42 and 43 of Book 1 Section 8.2.3) Procedure: Application Selection with PSE process is performed for all supported priority hierarchies. Pass Criteria: The terminal shall accept the card LT shall receive a second READ RECORD command with SFI coded according to SFI returned in FCI of the SELECT PSE command.
Page 108
2CB.006.00 Reading the Directory

Test No. 2CB.006.00 Objective: To ensure that if the terminal supports selection with PSE, it accepts any supported value for the SFI of the directory file of a DDF. Reference: 2RB.007.0 - Book 1 Section 8.2.4 - Reading the Directory Conditions: Terminal supports selection with PSE PSE contains a directory file with one entry for a DDF SFI of Directory is coded with different values in FCI of DDF Procedure: Application Selection with PSE phase is performed with LT for all supported values of SFI Pass Criteria: The LT shall receive a READ RECORD command for all values of SFI of DDF tested
2CB.007.00 Terminals List of Supported Applications

Test No. 2CB.007.00 Objective: To verify that the terminal maintains a list of application with their AIDs. Reference: 2RB.008.0 - Book 1 Section 8.3 - Terminals List of Supported Applications Conditions: LT does not support PSE selection in order to force the terminal to apply another selection technique ( by using its list of AIDs ). Procedure: Application Selection with AID is performed with LT Pass Criteria: The terminal generates SELECT command for each AID stored within the terminal.
Page 109
2CB.010.00 Matching AIDS: same AID criteria supported

Test No. 2CB.010.00 Objective: To ensure that the terminal keeps for each application an indication of which matching criteria to use and in particular that the terminal is able to support AID match AID kept in terminal criteria Reference: 2RB.012.0 - Book 1 Section 8.3.1 - Matching AIDS: same AID criteria supported Conditions: LT contains an application with AID matching AID kept in terminal Terminal supports AID match AID kept in terminal criteria for this application A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed with LT Pass Criteria: The terminal shall accept the card. Terminal shall indicate to cardholder which application can be selected
Page 110
2CB.011.00 Matching AIDs: AID beginning with Terminal AID criteria supported
Test No. 2CB.011.00 Objective: To ensure that the terminal keeps for each application an indication of which matching criteria to use and in particular that the terminal is able to support AID beginning with terminal AID criteria Reference: 2RB.012.1 - Book 1 Section 8.3.1 - Matching AIDs: AID beginning with Terminal AID criteria supported Conditions: LT contains several applications. The beginning of the AID of these applications is identical and match the beginning of one of the AID kept in terminal Application have different priorities in the LT Terminal supports several AID but one of the supported AID has a value matching the beginning of all AID in LT Terminal supports AID beginning with terminal AID criteria for this AID A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed with LT Pass Criteria: The terminal shall accept the card . Terminal shall indicate to cardholder which application can be selected
Page 111
2CB.012.00 Selection Using the Payment Systems Directory: SELECT PSE

Test No. 2CB.012.00 Objective: To ensure that if the terminal supports selection with PSE, it sends a SELECT 1PAY.SYS.DDF01 command Reference: 2RB.013.0 - Book 1 Section 8.3.2 - Selection Using the Payment Systems Directory: SELECT PSE Conditions: Terminal supports selection with PSE Procedure: Application Selection with PSE process is performed. Pass Criteria: LT shall receive a SELECT 1PAY.SYS.DDF01 command
2CB.013.00 Selection Using the Payment Systems Directory: Card Blocked or Command Not Supported
Test No. 2CB.013.00 Objective: To ensure that if the terminal supports selection with PSE, and card returns 6A 81 in response to the SELECT PSE command, the terminal terminates the transaction. Reference: 2RB.014.0 - Book 1 Section 8.3.2 - Selection Using the Payment Systems Directory: Card Blocked or Command Not Supported Conditions: Terminal supports selection with PSE LT returns 6A 81 to SELECT PSE command Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall terminate the transaction.
Page 112
2CB.014.00 Selection Using the Payment Systems Directory: SELECT PSE returns an error
Test No. 2CB.014.00 Objective: To ensure that if the terminal supports selection with PSE, and card returns status other than 90 00 or 6A 81 in response to the SELECT PSE command, the terminal switches to the list of applications method. Reference: 2RB.015.0 - Book 1 Section 8.3.2 - Selection Using the Payment Systems Directory: SELECT PSE returns an error Conditions: Terminal supports selection with PSE LT returns status other than 90 00 or 6A 81 to SELECT PSE command Procedure: Application Selection with PSE process is performed for all status tested. Pass Criteria: Terminal shall use the list of applications method.
2CB.016.00 Indicating end of record

Test No. 2CB.016.00 Objective: To ensure that if the terminal supports selection with PSE, the terminal selects PSE and sends READ RECORD commands until card responds with 6A 83 . Reference: 2RB.017.0 - Book 1 Section 8.3.2 - Indicating end of record Conditions: Terminal supports selection with PSE LT contains several entries and records Procedure: Application Selection with PSE process is performed. Pass Criteria: LT shall receive a sequence of READ RECORD command until the LT answers with 6A 83
Page 113
2CB.017.00 Directory empty or not present

Test No. 2CB.017.00 Objective: To ensure that if the terminal supports selection with PSE, and the card answers with 6A 83 to a READ RECORD for record number 1, the terminal switches to the list of applications method. Reference: 2RB.018.0 - Book 1 Section 8.3.2 - Directory empty or not present Conditions: Terminal supports selection with PSE LT answers with 6A 83 to a READ RECORD for record number 1 Procedure: Application Selection with PSE process is performed. Pass Criteria: LT shall receive a sequence of SELECT AID commands after the LT returns 6A 83 to READ RECORD for record number 1
2CB.018.00 Directory entry processing

Test No. 2CB.018.00 Objective: To ensure that if the terminal supports selection with PSE, the terminal begins with the first entry of first record of the directory file and processes each entry in turn Reference: 2RB.019.0 - Book 1 Section 8.3.2 - Directory entry processing Conditions: Terminal supports selection with PSE LT contains a Directory file with several entries in one record Terminal supports all ADF listed in the directory of the LT (for selection process only) A list is presented to the cardholder. Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall accept the card Terminal shall indicate to cardholder which application can be selected
Page 114
2CB.019.00 Candidate list

Test No. 2CB.019.00 Objective: To ensure that if the terminal supports selection with PSE, the terminal adds the application to the candidate list whenever an entry in directory file matches the name of one application supported by the terminal Reference: 2RB.020.0 - Book 1 Section 8.3.2 - Candidate list Conditions: Terminal supports selection with PSE LT contains a Directory file with several entries. Terminal supports all ADF listed in the directory of the LT (for selection process only) A list is presented to the cardholder. Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall accept the card Terminal shall indicate to cardholder which application can be selected
2CB.020.00 Candidate list (implied)

Test No. 2CB.020.00 Objective: To ensure that if the terminal supports selection with PSE, the terminal does not add the application to the candidate list whenever an entry in directory file does not match the name of one application supported by the terminal Reference: 2RB.020.1 - Book 1 Section 8.3.2 - Candidate list (implied) Conditions: Terminal supports selection with PSE LT contains a Directory file with one entry not supported by terminal. LT contains only the application listed in Directory file Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall reject the card (no application mutually supported)
Page 115
2CB.021.00 DDF entry

Test No. 2CB.021.00 Objective: To ensure that if the terminal supports selection with PSE, the terminal is able to process DDF entries Reference: 2RB.021.0 - Book 1 Section 8.3.2 - DDF entry Conditions: Terminal supports selection with PSE. LT contains a Directory file with one entry for a DDF. DDF of LT contains several applications. A list is presented to the cardholder. Terminal supports all ADF listed in the directory of the LT (for selection process only). Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall accept the card Terminal shall indicate to cardholder which application can be selected
Page 116
2CB.022.00 DDF entry failed

Test No. 2CB.022.00 Objective: To ensure that if the terminal supports selection with PSE, and if a SELECT DDF command returns a status different from 90 00, the terminal shall resume processing the previously interrupted directory at the point of interruption Reference: 2RB.021.1 - Book 1 Section 8.3.2 - DDF entry failed (implied) Conditions: Terminal supports selection with PSE. LT contains a Directory file with one entry for a DDF and others AIDs (before and after DDF entry). SELECT DDF returns status different from 90 00 A list is presented to the cardholder. Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall accept the card. Terminal shall indicate to cardholder which application can be selected
Page 117
2CB.023.00 Candidate List empty after selection with PSE

Test No. 2CB.023.00 Objective: To ensure that if the terminal supports selection with PSE, and if steps yield no directory entries that match applications supported by the terminal, the terminal switches to the list of applications method. Reference: 2RB.021.2 - Book 1 Section 8.3.2 - Candidate List empty after selection with PSE Conditions: Terminal supports selection with PSE LT supports PSE No directory entries matches applications supported by the terminal during SELECT PSE processing Procedure: Application Selection with PSE process is performed. Pass Criteria: The terminal shall switch to the AID list method
2CB.024.00 Selection using a list of AIDs

Test No. 2CB.024.00 Objective: To ensure that the terminal is able to manage a selection using a list of AIDs Reference: 2RB.022.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs Conditions: Terminal supports several Application Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall accept the card LT shall receive SELECT AID commands for each application supported by the terminal
Page 118
2CB.024.01 Selection using a list of AIDs: SELECT command

Test No. 2CB.024.01 Objective: To ensure that if the terminal uses the list of AID method, it issues the first SELECT command using the first AID in the list Reference: 2RB.022.1 - Book 1 Section 8.3.3 - Selection using a list of AIDs: SELECT command Conditions: Terminal supports several applications Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall accept the card LT shall receive the first SELECT AID command with the first AID of the terminal list of AID
2CB.025.00 Selection using a list of AIDs: SELECT fails

Test No. 2CB.025.00 Objective: To ensure that the terminal terminates the transaction if the card answers with 6A 81 to a SELECT command Reference: 2RB.023.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs: SELECT fails Conditions: The LT answers with 6A 81 to a SELECT Application command. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall terminate the transaction after the SELECT Application response is returned by the LT
Page 119
2CB.025.06 DF name and AID identical & SELECT command successful

Test No. 2CB.025.06 Objective: To ensure that if the DF name and the AID are identical, and SELECT command is successful (SW1 SW2 = '9000'), the terminal adds the FCI information from the selected file to the candidate list and issues another SELECT command using the next AID in its list. Reference: 2RB.023.6 - Book 1 Section 8.3.3 - DF name and AID identical & SELECT command successful Conditions: Terminal supports selection by AID Terminal supports at least two applications LT supports at least the first application presented in the first SELECT command (AID and DF name are identical) The LT answers with 90 00 to the first SELECT command Procedure: Application selection with the list of AID is performed. Pass Criteria: The terminal shall accept the card The terminal shall issue at least three SELECT command including a "final" SELECT command
Page 120
2CB.026.05 DF name and AID identical & application blocked

Test No. 2CB.026.05 Objective: To ensure that if the DF name and the AID are identical, and application is blocked (SW1 SW2 = '6283'), the terminal issues another SELECT command using the next AID in its list without adding the DF name to the candidate list. Reference: 2RB.024.5 - Book 1 Section 8.3.3 - DF name and AID identical & application blocked Conditions: Terminal supports selection by AID Terminal supports at least two applications The LT answers with 62 83 to the first SELECT command Procedure: Application selection with the list of AID is performed. Pass Criteria: The terminal shall accept the card The terminal shall issue at least two SELECT command The first AID that responded with 62 83 shall not be a part of the candidate list for final select.
Page 121
2CB.028.00 Selection using a list of AIDs

Test No. 2CB.028.00 Objective: To ensure that the terminal proceeds to SELECT the next application in its AID list following a status different from 90 00 or 6A 81 or 62 83 returned by the card and does not add the AID in the candidate list Reference: 2RB.026.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs Conditions: The LT answers with different status different from 90 00 or 6A 81 or 62 83 to SELECT Application command for a specific AID. (test is made with 2 status) Terminal supports at least 2 AIDs A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall accept the card After having sent status different from 90 00 or 6A 81 or 62 83 in answer to SELECT the specific AID above, the LT shall receive SELECT AID with AID of next application in the terminal AID list. Terminal shall indicate to cardholder which application can be selected
Page 122
2CB.029.00 Selection using a list of AIDs: candidate list completion

Test No. 2CB.029.00 Objective: To ensure that the terminal completes the candidate list when there is no more AID to select in the terminal list. Reference: 2RB.027.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs: candidate list completion Conditions: The LT contains one AID not supported by the terminal. Terminal supports at least 2 AIDs also supported by the LT A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall accept the card The LT shall receive SELECT AID command for all AID in the terminal list. Terminal shall indicate to cardholder which application can be selected
Page 123
2CB.031.00 Application Selection Indicator: One Occurrence Permitted

Test No. 2CB.031.00 Objective: To ensure that if the DFNAME in the ICC is longer than the AID in the terminal, but they are identical up to and including the last character in the terminal AID, the terminal shall check the Application Selection indicator. If the indicator says only one occurrence is allowed the terminal does not add the AID to the candidate list and reissues the SELECT command with P2 set to 02 Reference: 2RB.029.00 Book 1 Section 8.3.3 - Application Selection Indicator: One Occurrence Permitted Conditions: DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID Terminal Application Selection Indicator only allows one occurrence for selected AID
Procedure: Application Selection using list of AID is performed. Pass Criteria: After SELECT AID command, the LT shall receive SELECT AID with P2 option set to next until LT answer is '6A 82'. The terminal will not store the first AID as a selectable application
Page 124
2CB.031.06 DF name longer than AID & multiple occurrence & application not blocked
Test No. 2CB.031.06 Objective: To ensure that if the DF name in the ICC is longer than the AID in the terminal but are identical up to and including the last character in the terminal AID, the terminal shall check the Application Selection indicator. If the Application Selection Indicator indicates that multiple occurrence are permitted and if the application is not blocked, the terminal adds the AID to the candidate list and repeats the SELECT command using the same command data as before, but change P2 in the command to '02'. Reference: 2RB.029.2 - Book 1 Section 8.3.3 - DF name longer than AID & multiple occurrence & application not blocked Conditions: Terminal supports at least one AID DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID Terminal Application Selection Indicator allows multiple occurrence for selected AID LT answers '90 00' to the first SELECT NEXT command
Procedure: Application Selection using list of AID is performed. Pass Criteria: After SELECT AID command, the LT shall receive SELECT AID with P2 option set to next The terminal shall store the first AID in the candidate list
Page 125
2CB.031.07 DF name longer than AID & multiple occurrence & application blocked
Test No. 2CB.031.07 Objective: To ensure that if the DF name in the ICC is longer than the AID in the terminal , but they are identical up to and including the last character in the terminal AID , the terminal shall check the Application Selection indicator. If the Application Selection Indicator indicates that multiple occurrence are permitted and if the application is blocked, the terminal does not add the AID to the candidate list and repeats the SELECT command using the same command data as before, but change P2 in the command to '02'. Reference: 2RB.029.3 - Book 1 Section 8.3.3 - DF name longer than AID & multiple occurrence & application blocked Conditions: Terminal supports at least one AID DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID Terminal Application Selection Indicator allows multiple occurrence for selected AID LT answers '62 83' to the first SELECT command
Procedure: Application Selection using list of AID is performed. Pass Criteria: After SELECT AID command, the LT shall receive SELECT AID with P2 option set to next until LT answer is '6A 82'. The terminal shall not store the first AID as a selectable application.
Page 126
2CB.032.00 DFNAME is different from AID

Test No. 2CB.032.00 Objective: To ensure that the terminal does not repeat a SELECT command using partial name option if the DF Name returned in FCI is different or shorter than terminal AID used for selection, but continues processing with next AID in the terminal list. Reference: 2RB.029.1 - Book 1 Section 8.3.3 - DFNAME is different from AID (implied) Conditions: DF Name contained in FCI returned by the LT for first AID selection is shorter or different than terminal AID used for selection Terminal supports at least 2 AIDs A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall accept the card After having sent answer 90 00 and FCI with bad DF Name to first SELECT AID, the LT shall receive SELECT AID with AID of next application in the terminal AID list. Terminal shall indicate to cardholder which application can be selected
Page 127
2CB.034.00 Multiple occurrence of application: next option supported: 90 00

Test No. 2CB.034.00 Objective: To ensure that, if the card returns 90 00 to a SELECT command with next option, the terminal adds the DFNAME from the FCI of the selected file to the candidate list and continues processing Application selection. Reference: 2RB.031.0 - Book 1 Section 8.3.3 - Multiple occurrence of application: next option supported: 90 00 Conditions: DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID Terminals Application Selection Indicator allows multiple occurrences for the AID LT returns 90 00 to a SELECT command with next option (several applications with same beginning of AID in LT) A list is presented to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The LT shall receive a sequence of SELECT AID with P2 option set to next until LT answer is 6A 82. Terminal shall indicate to cardholder which application can be selected
Page 128
2CB.035.00 Multiple occurrence of application: next option failed: 62 83

Test No. 2CB.035.00 Objective: To ensure that the terminal does not add the AID in the candidate list when the card returns 62 83 to a SELECT command with next option and proceeds to check for the possibility of multiple occurrences of the application in the ICC before selecting the next AID from the list. Reference: 2RB.031.1 - Book 1 Section 8.3.3 - Multiple occurrence of application: next option failed: 62 83 Conditions: DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID Terminal supports AID beginning with terminal AID criteria for the above AID LT returns 62 83 to the first SELECT command with next option LT returns 6A 82 to following SELECT command(s) with next option Terminal supports at least 2 AIDs Procedure: Perform Application Selection using list of AIDs. Pass Criteria: After having received status 62 83 in the response to the selection for a specific AID, the application shall send another SELECT command with next option for the same AID. The candidate list shall not contain the blocked application. A response code equal to 62 83 indicates that the application is blocked.
Page 129
2CB.036.00 Multiple occurrence of application: next option failed: other

Test No. 2CB.036.00 Objective: To ensure that the terminal proceeds to SELECT the next application in its AID list, if the card returns status different from 90 00 or 62 83 to a SELECT command with next option. Reference: 2RB.031.2 - Book 1 Section 8.3.3 - Multiple occurrence of application: next option failed: other Conditions: DF Name contained in FCI returned by the LT for first AID selection is longer than terminal AID used for selection but they are identical up to and including the last character in the terminal AID LT returns status different from 90 00or 62 83 to a SELECT command with next option (test is made with several status) Terminal supports at least 2 AIDs Procedure: Application Selection using list of AID is performed. Pass Criteria: After having sent status different from 90 00or 62 83 in answer to SELECT the specific AID above, the LT shall receive SELECT AID with AID of next application in the terminal AID list.
2CB.037.00 Final Selection: no mutually supported application

Test No. 2CB.037.00 Objective: To ensure that the terminal terminate the transaction if there is no mutually supported application (candidate list empty). Reference: 2RB.032.0 - Book 1 Section 8.3.4 - Final Selection: no mutually supported application Conditions: There is no matching AID between LT and Terminal Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall terminate the transaction
Page 130
2CB.038.00 Final Selection: one mutually supported application

Test No. 2CB.038.00 Objective: To ensure that if only one AID is mutually supported and b8 of Application priority indicator equals 0, the terminal selects this AID. Reference: 2RB.033.0 - Book 1 Section 8.3.4 - Final Selection: one mutually supported application Conditions: There is one matching AID between LT and Terminal b8 of Application Indicator returned by LT equals 0 Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall select the AID.
2CB.039.00 Final Selection: cardholder confirmation

Test No. 2CB.039.00 Objective: To ensure that if only one AID is mutually supported and b8 of Application priority indicator equals 1 and terminal provides for cardholder confirmation, the terminal requests confirmation and selects the application if the cardholder approves. Reference: 2RB.034.0 - Book 1 Section 8.3.4 - Final Selection: cardholder confirmation Conditions: There is one matching AID between LT and Terminal b8 of Application Indicator returned by LT equals 1 The terminal provides for cardholder confirmation The cardholder approves. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall request confirmation of the cardholder and shall generate a SELECT AID command as response to that confirmation.
Page 131
2CB.040.00 Final Selection: no cardholder confirmation

Test No. 2CB.040.00 Objective: To ensure that if only one AID is mutually supported and b8 of Application priority indicator equals 1 and terminal does not provide for cardholder confirmation, the terminal terminates the transaction. Reference: 2RB.035.0 - Book 1 Section 8.3.4 - Final Selection: no cardholder confirmation Conditions: There is one matching AID between LT and Terminal b8 of Application Indicator returned by LT equals 1 The terminal does not provide for cardholder confirmation Procedure: Application Selection using list of AID or PSE method. Pass Criteria: The terminal shall terminate the transaction
2CB.041.00 Final Selection: cardholder does not approve

Test No. 2CB.041.00 Objective: To ensure that if only one AID is mutually supported and b8 of Application priority indicator equals 1 and terminal provides for cardholder confirmation and cardholder does not approve, the terminal terminates the transaction. Reference: 2RB.036.0 - Book 1 Section 8.3.4 - Final Selection: cardholder does not approve Conditions: There is one matching AID between LT and Terminal b8 of Application Indicator returned by LT equals 1 The terminal provides for cardholder confirmation Cardholder does not approve Procedure: Application Selection using list of AID or PSE method. Pass Criteria: The terminal shall terminate the transaction
Page 132
2CB.042.00 Displaying Application to Cardholder: priority sequence

Test No. 2CB.042.00 Objective: To ensure that if multiple applications are mutually supported and list display is supported, the terminal displays a list in priority sequence. Reference: 2RB.038.0 - Book 1 Section 8.3.4 - Displaying Application to Cardholder: priority sequence Conditions: Terminal has no preferred order of display. There are several matching AIDs between LT and Terminal Applications have different priorities Terminal supports list display and a list is presented to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall display a list of applications ordered in priority sequence (highest priority first)
Page 133
2CB.049.00 Terminal Selection of Application without Cardholder Assistance

Test No. 2CB.049.00 Objective: To ensure that if multiple applications are mutually supported and there is priority sequence and no confirmation is required, the terminal selects the application with highest priority. Reference: 2RB.041.0 - Book 1 Section 8.3.4 - Terminal Selection of Application without Cardholder Assistance Conditions: Terminal does not support the preferred method as described in point 4 of final selection EMV process description There are several matching AIDs between LT and Terminal Applications have different priorities No confirmation is required in Application priority indicator Terminal does not present the list to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall select the application with highest priority and shall generate the SELECT AID command (with AID=application with highest priority).
Page 134
2CB.050.00 Terminal Selection of Application without Cardholder Assistance: confirmation required

Test No. 2CB.050.00 Objective: To ensure that if multiple applications are mutually supported and list display is not supported, and there is priority sequence and confirmation is required for some applications, the terminal selects the application with highest priority excluding application requiring confirmation Reference: 2RB.042.0 - Book 1 Section 8.3.4 - Terminal Selection of Application without Cardholder Assistance: confirmation required Conditions: There are several matching AIDs between LT and Terminal Applications have different priorities Application with highest priority requires cardholder confirmation Terminal does not present the list to the cardholder. Procedure: Application Selection using list of AID is performed. Pass Criteria: The terminal shall select the application with highest priority (excluding application requiring cardholder confirmation) and shall generate the SELECT AID command (with AID = application with highest priority excluding application requiring confirmation).
Page 135
2CB.053.00 Final Selection of Application from Candidate List: list of AID

Test No. 2CB.053.00 Objective: To ensure that once an application is selected the terminal issue a SELECT command using the DF Name read in FCI if selection was performed using list of AID. Reference: 2RB.043.0 - Book 1 Section 8.3.4 - Final Selection of Application from Candidate List: List of AID Conditions: There are several matching AIDs between LT and Terminal Applications have different priorities Terminal uses selection using list of AID process Procedure: Application Selection using list of AID is performed. Pass Criteria: After having received a SELECT command for all AID in the terminal list, the LT shall receive a SELECT command with DFNAME of the application selected
Page 136
2CB.054.00 Final Selection of Application from Candidate List: PSE

Test No. 2CB.054.00 Objective: To ensure that if the Terminal supports selection with PSE and performs selection with PSE, it issues a SELECT command using the ADF Name read in directory. Reference: 2RB.043.1 - Book 1 Section 8.3.4 - Final Selection of Application from Candidate List: PSE Conditions: LT supports PSE Terminal supports selection with PSE There are several matching AID founded between LT and Terminal Applications have different priorities Terminal uses selection using PSE process Procedure: Application Selection using PSE is performed. Pass Criteria: The terminal shall accept the card After having received READ RECORD for all records of the card directory, the LT shall receive a SELECT command with ADFName of the application with highest priority. Terminal shall select the application
Page 137
2CB.055.00 Final Selection of Application from Candidate List: SELECT status different from 90 00
Test No. 2CB.055.00 Objective: To ensure that if the card returns a status different from '90 00' to the SELECT command sent to select the chosen application, the terminal removes the application from the list of mutually supported applications and switches back to the final application selection process Reference: 2RB.044.0 - Book 1 Section 8.3.4 - Final Selection of Application from Candidate List: SELECT status different from '90 00' Conditions: There are several matching AIDs between LT and Terminal Applications have different priorities LT returns status different from '90 00' after final selection Procedure: Application Selection using PSE or List of AID is performed. Pass Criteria: Terminal shall remove the application from the candidate list and shall switch back to the final selection process after the card answered to final SELECT with status different from '90 00' The candidate list generated during the second selection process shall not contain anymore the application used during the above final SELECT
Page 138
Security Aspects
2CC.003.00 Terminal shall be able to store 6 CA Index per RID
Test No. 2CC.003.00 Objective: To ensure that if the terminal supports Static Data Authentication, it is able to store 6 Certification Authority Public Keys and the key-related information to be used with the key and it is able, given RID and Certification Authority Public Key Index, to locate such key. Reference: 2RC.003.00 - Book 2 - Section 5 - Requirements Terminal Must Meet to Perform SDA Conditions: Terminal is loaded with 6 Certification Authority Public Keys and associated data Static signature in LT is good (for each combination above) Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 139
2CC.004.00 Algorithm For SDA

Test No. 2CC.004.00 Objective: To ensure that the terminal supports reversible algorithm for Static Data Authentication as specified in Book 2, A2.1 Reference: 2RC.004.0 - Book 2 - Section 5 - Algorithm For SDA Conditions: Static signature in LT is good (it is calculated using the reversible algorithm) Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 140
2CC.006.00 Bit Length of all Moduli

Test No. 2CC.006.00 Objective: To ensure that the terminal supports Moduli with a bit length which is a multiple of 8 for Static Data Authentication Reference: 2RC.006.0 - Book 2 - Section 5.1 - Bit Length of all Moduli Conditions: Static signature in LT is good length of moduli used (CA and Issuer) are multiple of 8 Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 141
2CC.007.00 Value of Certification Authority Public Key Exponent

Test No. 2CC.007.00 Objective: To ensure that the terminal supports value 3 or 2 + 1 as exponent for Certification Authority Public Key for Static Data Authentication Reference: 2RC.007.0, Book 2 - Section 5.1 - Value of Certification Authority Public Key Exponent Conditions: Static signature in LT is good Exponent of Certification Authority Public Key is 3 or 2 tested) Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
16 16
+ 1 (2 values
Page 142
2CC.008.00 Value of Issuer Public Key Exponent

Test No. 2CC.008.00 Objective: To ensure that the terminal supports value 3 or 2 Issuer Public Key for Static Data Authentication
16
+ 1 as exponent for
Reference: 2RC.008.0, Book 2 - Section5.1 - Value of Issuer Public Key Exponent Conditions: Static signature in LT is good Exponent of Issuer Public Key is 3 or 216 + 1 (2 values tested) Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 143
2CC.009.00 Data missing: CA Public Key Index

Test No. 2CC.009.00 Objective: To ensure that if the Certification Authority Public Key index is missing in ICC, the terminal fails the Static Data Authentication Reference: 2RC.009.0 , Book 2 - Section 5.1 - Data missing: CA Public Key Index Conditions: Index of Certification Authority Public Key is missing in ICC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 144
2CC.010.00 Data missing: Issuer PK Certificate

Test No. 2CC.010.00 Objective: To ensure that if the Issuer Public key Certificate is missing in ICC, the terminal fails the Static Data Authentication Reference: 2RC.009.1, Book 2 - Section 5.1 - Data missing: Issuer PK Certificate Conditions: Issuer Public Key Certificate is missing in ICC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 145
2CC.011.00 Data missing: Issuer PK Exponent

Test No. 2CC.011.00 Objective: To ensure that if the Issuer Public key Exponent is missing in ICC, the terminal fails the Static Data Authentication Reference: 2RC.009.2, Book 2 - Section 5.1 - Data missing: Issuer PK Exponent Conditions: Issuer Public key Exponent is missing in ICC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 146
2CC.012.00 Data missing: Signed Static Application data

Test No. 2CC.012.00 Objective: To ensure that if the Signed Static Application Data is missing in ICC, the terminal fails the Static Data Authentication Reference: 2RC.009.3, Book 2 - Section 5.1 - Data missing: Signed Static Application data Conditions: Signed Static Application Data is missing in ICC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 147
2CC.014.00 Retrieving CA Public Key used to Perform SDA: Key absent

Test No. 2CC.014.00 Objective: To ensure that if the terminal supports Static Data Authentication, if no Certification Authority Public Keys is available for a given RID and Certification Authority Public Key Index, the terminal fails the Static Data Authentication. Reference: 2RC.011.0 , Book 2 - Section 5.2 - Retrieving CA Public Key used to Perform SDA: Key absent Conditions: Terminal does not contain the Certification Authority Public Key referenced in LT Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 148
2CC.015.00 Length of Issuer Public Key Certificate

Test No. 2CC.015.00 Objective: To ensure that if the terminal supports Static Data Authentication, and if Issuer Public Key Certificate has a length different from Certification Authority Public Key Modulus, the terminal fails the Static Data Authentication. Reference: 2RC.012.0, Book 2 - Section 5.3 - Length of Issuer Public Key Certificate Conditions: Issuer Public Key Certificate in LT has a length different from Certification Authority Public Key Modulus in Terminal Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 149
2CC.017.00 Recovered Data Trailer not equal to BC

Test No. 2CC.017.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Data Trailer recovered from the Issuer Public Key Certificate does not equal BC Reference: 2RC.014.0 , Book 2 - Section 5.3 - Recovered Data Trailer not equal to BC Conditions: Issuer Public Key Certificate in LT is calculated with a Data Trailer different from BC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 150
2CC.018.00 Recovered Data Header not equal to 6A

Test No. 2CC.018.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Data Header recovered from the Issuer Public Key Certificate does not equal 6A Reference: 2RC.015.0 , Book 2 - Section 5.3 - Recovered Data Header not equal to 6A Conditions: Issuer Public Key Certificate in LT is calculated with a Data Header different from 6A Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 151
2CC.019.00 Certificate Format not equal to 02

Test No. 2CC.019.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Certificate Format recovered from Issuer Public Key Certificate does not equal 02 Reference: 2RC.016.0 , Book 2 - Section 5.3 - Certificate Format not equal to 02 Conditions: Issuer Public Key Certificate in LT is calculated with a Certificate Format different from 02 Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 152
2CC.020.00 Difference between calculated Hash Result and recovered Hash Result
Test No. 2CC.020.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the calculated Hash Result is different from the Hash Result recovered from the Issuer Public Key Certificate Reference: 2RC.017.0 , Book 2 - Section 5.3 - Difference between calculated Hash Result and recovered Hash Result Conditions: Issuer Public Key Certificate in LT is calculated with a bad Hash value Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 153
2CC.021.00 IIN does not match leftmost 3-8 PAN digits

Test No. 2CC.021.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Recovered Issuer Identification Number does not match the leftmost 3-8 PAN digits Reference: 2RC.018.0 , Book 2 - Section 5.3 - IIN does not match leftmost 3-8 PAN digits Conditions: Issuer Public Key Certificate in LT is calculated with IIN different from leftmost 3-8 PAN digits Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 154
2CC.022.00 Certificate Expiration Date earlier than todays date

Test No. 2CC.022.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Certificate Expiration Date has expired Reference: 2RC.019.0 , Book 2 - Section 5.3 - Certificate Expiration Date earlier than todays date Conditions: Issuer Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 155
2CC.023.00 RID, CA Public Key Index and Certificate Serial Number not valid
Test No. 2CC.023.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the concatenation of RID, CA Public Key Index and Certificate Serial Number indicates a revocated Certificate Reference: 2RC.020.0 , Book 2 - Section 5.3 - RID, CA Public Key Index and Certificate Serial number not valid Conditions: Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number such as the certificate is in the revocation list of the terminal Terminal supports revocation of the Issuer Public Key Certificate Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 156
2CC.024.00 Issuer Public Key Algorithm not recognized

Test No. 2CC.024.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Issuer Public Key Algorithm is not supported (different from 01) Reference: 2RC.021.0 , Book 2 - Section 5.3 - Issuer Public Key Algorithm not recognised Conditions: Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value different from 01 Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 157
2CC.026.00 Signed Static Application Data Length not OK

Test No. 2CC.026.00 Objective: To ensure that if the terminal supports Static Data Authentication, and if Signed Static Application Data has a length different from Issuer Public Key Modulus, the terminal fails the Static Data Authentication. Reference: 2RC.023.0 , Book 2 - Section 5.4 - Signed Static Application Data Length not OK Conditions: Signed Static Application Data has a length different from Issuer Public Key Modulus in ICC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 158
2CC.028.00 Recover Data Trailer not equal to BC

Test No. 2CC.028.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Data Trailer recovered from Signed Static Application Data does not equal BC Reference: 2RC.025.0 , Book 2 - Section 5.4 - Recover Data Trailer not equal to BC Conditions: Signed Static Application Data in LT is calculated with a Data Trailer different from BC Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 159
2CC.029.00 Recover Data Header not equal to 6A

Test No. 2CC.029.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Data Header recovered from the Signed Static Application Data does not equal 6A Reference: 2RC.026.0 , Book 2 - Section 5.4 - Recover Data Header not equal to 6A Conditions: Signed Static Application Data in LT is calculated with a Data Header different from 6A Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 160

Test No. 2CC.030.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the Certificate Format recovered from Signed Static Application Data does not equal 03 Reference: 2RC.027.0 , Book 2 - Section 5.4 - Certificate Format not equal to 03 Conditions: Signed Static Application Data in LT is calculated with a Certificate Format different from 03 Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 161
Test No. 2CC.031.00 Objective: To ensure that the terminal fails the Static Data Authentication, if the calculated Hash Result is different from the Hash Result recovered from Signed Static Application Data Reference: 2RC.028.0 , Book 2 - Section 5.4 - Difference between calculated Hash Result and recovered Hash Result Conditions: Signed Static Application Data in LT is calculated with a bad Hash value Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 162
2CC.032.00 SDA Tag List in Static Data Authentication

Test No. 2CC.032.00 Objective: To ensure that the terminal checks that SDA Tag List contains only AIP in SDA Reference: 2RC.032.0 - Book 1 - Section 5.1 & Book 2 Section 5.4 - Static Data to be Authenticated Conditions: ICC and Terminal support SDA CDOL1 requests also TSI and TVR SDA Tag List contains AFL Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline SDA failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 163
2CC.033.00 Data Authentication Code Stored

Test No. 2CC.033.00 Objective: To ensure that the terminal stores the Data Authentication Code in tag '9F 45' Reference: 2RC.029.0 - Book 2 - Section 5.4 - Data Authentication Code Conditions: ICC and Terminal support SDA
CDOL1 requests TSI ,TVR and Tag '9F 45' Data Authentication is 'DA C0'
Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline SDA succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed Value of Tag '9F 45' is 'DA C0' in CDOL1
Page 164
2CC.036.00 Terminal shall be able to store 6 CA Index per RID

Test No. 2CC.036.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, it is able to store 6 Certification Authority Public Keys and the key-related information to be used with the key and it is able, given RID and Certification Authority Public Key Index, to locate such key. Reference: 2RC.029.00, Book 2 - Section 6 - Requirements Terminal Must Meet to Support DDA Conditions: Terminal is loaded with 6 Certification Authority Public Keys and associated data LT contains several combinations of RID and CA Public key index Dynamic signature in LT is good (for each combination above) Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4= 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 165
2CC.037.00 Algorithm for DDA

Test No. 2CC.037.00 Objective: To ensure that the terminal supports reversible algorithm for Dynamic Data Authentication as specified in Book 2, A2.1 Reference: 2RC.034.0 , Book 2, A2.1- Algorithm for DDA Conditions: Dynamic signature computed by LT is good (it is calculated using the reversible algorithm) Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 166
2CC.039.00 Bit Length of All Moduli

Test No. 2CC.039.00 Objective: To ensure that the terminal supports Moduli with a bit length which is a multiple of 8 for Dynamic Data Authentication Reference: 2RC.036.0 , Book 2 - Section 6.1 - Bit Length of All Moduli Conditions: Dynamic signature computed by LT is good length of moduli used (CA and Issuer an ICC) are multiple of 8 Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 167
2CC.040.00 Value of CA Public Key Exponent

Test No. 2CC.040.00 Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent for Certification Authority Public Key for Dynamic Data Authentication Reference: 2RC.037.0 , Book 2 - Section 6.1 - Value of CA Public Key Exponent Conditions: Dynamic signature computed by LT is good Exponent of Certification Authority Public Key is 3 or 216 + 1 (2 values tested) Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 168
2CC.041.00 Value of Issuer Public Key Exponent

Test No. 2CC.041.00 Objective: To ensure that the terminal supports value 3 or 2 Issuer Public Key for Dynamic Data Authentication
16
+ 1 as exponent for
Reference: 2RC.038.0 , Book 2 - Section 6.1 - Value of Issuer Public Key Exponent Conditions: Dynamic signature computed by LT is good Exponent of Issuer Authority Public Key is 3 or 216 + 1 (2 values tested) Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 169
2CC.042.00 Value of ICC Public Key Exponent

Test No. 2CC.042.00 Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent for ICC Public Key for Dynamic Data Authentication Reference: 2RC.039.0 , Book 2 - Section 6.1 - Value of ICC Public Key Exponent Conditions: Dynamic signature computed by LT is good Exponent of ICC Authority Public Key is 3 or 216 + 1 (2 values tested) Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 170
2CC.043.00 Data missing: CA Public Key Index

Test No. 2CC.043.00 Objective: To ensure that if the Certification Authority Public Key index is missing in ICC, the terminal fails the Dynamic Data Authentication Reference: 2RC.040.0 , Book 2 - Section 6.1 - Data missing: CA Public Key Index Conditions: Terminal and LT support Dynamic Data Authentication Index of Certification Authority Public Key is missing in ICC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 171
2CC.044.00 Data missing: Issuer Public Key Certificate

Test No. 2CC.044.00 Objective: To ensure that if the Issuer Public key Certificate is missing in ICC, the terminal fails the Dynamic Data Authentication Reference: 2RC.040.1 , Book 2 - Section 6.1 - Data missing: Issuer Public Key Certificate Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate is missing in ICC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 172
2CC.045.00 Data missing: Issuer PK Exponent

Test No. 2CC.045.00 Objective: To ensure that if the Issuer Public key Exponent is missing in ICC, the terminal fails the Dynamic Data Authentication Reference: 2RC.040.2 , Book 2 - Section 6.1 - Data missing: Issuer PK Exponent Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public key Exponent is missing in ICC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 173
2CC.046.00 Data missing: ICC Public Key Certificate

Test No. 2CC.046.00 Objective: To ensure that if the ICC Public key Certificate is missing in ICC, the terminal fails the Dynamic Data Authentication Reference: 2RC.040.3 , Book 2 - Section 6.1 - Data missing: ICC Public Key Certificate Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate is missing in ICC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 174
2CC.047.00 Data missing: ICC Public Key Exponent

Test No. 2CC.047.00 Objective: To ensure that if the ICC Public key Exponent is missing in ICC, the terminal fails the Dynamic Data Authentication Reference: 2RC.040.4 , Book 2 - Section 6.1 - Data missing: ICC Public Key Exponent Conditions: Terminal and LT support Dynamic Data Authentication ICC Public key Exponent is missing in ICC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TVR byte 1, bit 6 = 1 ie ICC data missing TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 175
2CC.049.00 Retrieving CA Public Key used to Perform DDA: Key absent

Test No. 2CC.049.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, if no Certification Authority Public Keys is available for a given RID and Certification Authority Public Key Index, the terminal fails the Dynamic Data Authentication Reference: 2RC.042.0 , Book 2 - Section 6.2 - Retrieving CA Public Key used to Perform DDA Conditions: Terminal and LT support Dynamic Data Authentication Terminal does not contain the Certification Authority Public Key referenced in LT CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 176
2CC.050.00 Length of Issuer Public Key Certificate

Test No. 2CC.050.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, and if Issuer Public Key Certificate has a length different from Certification Authority Public Key Modulus, the terminal fails the Dynamic Data Authentication. Reference: 2RC.043.0 , Book 2 - Section 6.3 - Length of Issuer Public Key Certificate Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT has a length different from Certification Authority Public Key Modulus in Terminal CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 177

Test No. 2CC.052.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Trailer recovered from the Issuer Public Key Certificate does not equal BC. Reference: 2RC.045.0 , Book 2 - Section 6.3 - Recover Data Trailer not equal to BC Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with a Data Trailer different from BC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 178

Test No. 2CC.053.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Header recovered from the Issuer Public Key Certificate does not equal 6A. Reference: 2RC.046.0 , Book 2 - Section 6.3 - Recover Data Header not equal to 6A Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with a Data Header different from 6A CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 179

Test No. 2CC.054.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Certificate Format recovered from Issuer Public Key Certificate does not equal 02. Reference: 2RC.047.0 , Book 2 - Section 6.3 - Certificate Format not equal to 02 Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with a Certificate Format different from 02 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 180
Test No. 2CC.055.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the calculated Hash Result is different from the Hash Result recovered from the Issuer Public Key Certificate. Reference: 2RC.048.0 , Book 2 - Section 6.3 - Difference between calculated Hash Result and recovered Hash Result Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with a bad Hash value CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 181
2CC.056.00 IIN does not match leftmost 3-8 PAN digits

Test No. 2CC.056.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Recovered Issuer Identification Number does not match the leftmost 3-8 PAN digits. Reference: 2RC.049.0 , Book 2 - Section 6.3 - IIN does not match leftmost 3-8 PAN digits Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with IIN different from leftmost 3-8 PAN digits CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 182

Test No. 2CC.057.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Certificate Expiration Date has expired. Reference: 2RC.050.0 , Book 2 - Section 6.3 - Certificate Expiration Date earlier than todays date Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 183
2CC.058.00 RID, CA Public Key Index and Certificate Serial Number not valid
Test No. 2CC.058.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the concatenation of RID, CA Public Key Index and Certificate Serial Number indicates a revocated Certificate. Reference: 2RC.051.0 , Book 2 - Section 6.3 - RID, CA Public Key Index and Certificate Serial number not valid Conditions: Terminal supports revocation of the Issuer Public Key Certificate Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with RID, CA Public Key Index and Certificate Serial Number such as the certificate is in the revocation list of the terminal CDOL1 requests TSI and TVR. Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 184
2CC.059.00 Issuer Public Key Algorithm not recognized

Test No. 2CC.059.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Issuer Public Key Algorithm is not supported (different from 01). Reference: 2RC.052.0 , Book 2 - Section 6.3 - Issuer Public Key Algorithm not recognised Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value different from 01 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 185
2CC.061.00 Length of ICC Public Key Certificate

Test No. 2CC.061.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, and if ICC Public Key Certificate has a length different from Issuer Public Key Modulus, the terminal fails the Dynamic Data Authentication. Reference: 2RC.054.0 , Book 2 - Section 6.4 - Length of ICC Public Key Certificate Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT has a length different from recovered Issuer Public Key Modulus CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 186

Test No. 2CC.063.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Trailer recovered from the ICC Public Key Certificate does not equal BC. Reference: 2RC.056.0 , Book 2 - Section 6.4 - Recover Data Trailer not equal to BC Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with a Data Trailer different from BC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 187

Test No. 2CC.064.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Header recovered from the ICC Public Key Certificate does not equal 6A. Reference: 2RC.057.0 , Book 2 - Section 6.4 - Recover Data Header not equal to 6A Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with a Data Header different from 6A CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 188

Test No. 2CC.065.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Certificate Format recovered from ICC Public Key Certificate does not equal 04. Reference: 2RC.058.0 , Book 2 - Section 6.4 - Certificate Format not equal to 04 Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with a Certificate Format different from 04 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 189
Test No. 2CC.066.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the calculated Hash Result is different from the Hash Result recovered from the ICC Public Key Certificate. Reference: 2RC.059.0 , Book 2 - Section 6.4 - Difference between calculated Hash Result and recovered Hash Result Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with a bad Hash value CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 190
2CC.067.00 Recovered PAN is not equal to read PAN

Test No. 2CC.067.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Recovered PAN does not match the PAN digits from the card. Reference: 2RC.060.0 , Book 2 - Section 6.4 - Recovered PAN is not equal to read PAN Conditions: Terminal and LT support Dynamic Data Authentication Issuer Public Key Certificate in LT is calculated with PAN different from PAN in LT CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 191

Test No. 2CC.068.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Certificate Expiration Date has expired. Reference: 2RC.061.0 , Book 2 - Section 6.4 - Certificate Expiration Date earlier than todays date Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with Certificate Expiration Date earlier than the current date CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 192
2CC.069.00 ICC Public Key Algorithm not recognized

Test No. 2CC.069.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the ICC Public Key Algorithm is not supported (different from 01). Reference: 2RC.062.0 , Book 2 - Section 6.4 - ICC Public Key Algorithm not recognised Conditions: Terminal and LT support Dynamic Data Authentication ICC Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value different from 01 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 193
2CC.071.00 Dynamic Signature generation

Test No. 2CC.071.00 Objective: To ensure that if Dynamic Data Authentication is supported, the terminal is able to issue an INTERNAL AUTHENTICATE command including data elements specified in DDOL. Reference: 2RC.064.0 , Book 2 - Section 6.5.1 - Dynamic Signature generation Conditions: Terminal and LT support Dynamic Data Authentication DDOL is present in LT Dynamic signature computed by LT is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded The LT shall receive an INTERNAL AUTHENTICATE command with concatenation of data in DDOL according to rule described in Book 3 Section 1.4 TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 194
2CC.072.00 Default DDOL

Test No. 2CC.072.00 Objective: To ensure that if Dynamic Data Authentication is supported, and card does not contain DDOL, the terminal is able to use its default DDOL. Reference: 2RC.065.0 , Book 2 - Section 6.5.1 - Default DDOL Conditions: Terminal and LT support Dynamic Data Authentication DDOL is absent in LT Default DDOL is present in terminal Dynamic signature computed by LT is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded The LT shall receive an INTERNAL AUTHENTICATE command with concatenation of data in default DDOL according to rule described in Book 3 Section1.4 TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 195
2CC.074.00 Source of Unpredictable Number

Test No. 2CC.074.00 Objective: To ensure that if Dynamic Data Authentication is supported and the DDOL requests an unpredictable Number, the terminal send an INTERNAL AUTHENTICATE command containing this number on 4 bytes Reference: 2RC.066.0 , Book 2 - Section 6.5.1 - Source of Unpredictable Number Conditions: Terminal and LT support Dynamic Data Authentication DDOL requests 9F 37 on 4 bytes Dynamic signature computed by LT is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded The LT shall receive an INTERNAL AUTHENTICATE command with unpredictable Number contained in the data field TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 196
2CC.075.00 DDOL does not contain unpredictable Number

Test No. 2CC.075.00 Objective: To ensure that if Dynamic Data Authentication is supported and the DDOL in card does not request an unpredictable Number, the terminal fails the Dynamic Data Authentication Reference: 2RC.067.0 , Book 2 - Section 6.5.1 - DDOL does not contain unpredictable number Conditions: Terminal and LT support Dynamic Data Authentication DDOL in LT does not request 9F 37 default DDOL in terminal requests 9F 37 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 197
2CC.076.00 Default DDOL does not contain unpredictable Number

Test No. 2CC.076.00 Objective: To ensure that if Dynamic Data Authentication is supported, and the card does not contain DDOL and the default DDOL in terminal does not request an unpredictable Number, the terminal fails the Dynamic Data Authentication Reference: 2RC.068.0 , Book 2 - Section 6.5.1 - Default DDOL does not contain unpredictable number Conditions: Terminal and LT support Dynamic Data Authentication DDOL is absent in LT default DDOL in terminal does not request 9F 37 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 198
2CC.078.00 Signed Dynamic Application Data Length not OK

Test No. 2CC.078.00 Objective: To ensure that if the terminal supports Dynamic Data Authentication, and if Signed Dynamic Application Data has a length different from ICC Public Key Modulus, the terminal fails the Dynamic Data Authentication. Reference: 2RC.070.0 , Book 2 - Section 6.5.2 - Signed Dynamic Application Data Length not OK Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data computed by LT has a length different from ICC Public Key Modulus CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 199
2CC.079.00 Recovery Function

Test No. 2CC.079.00 Objective: To ensure that the terminal is able to perform the recovery function on the Signed Dynamic Application Data for Dynamic Data Authentication as specified in Book 2, A2.1 Reference: 2RC.071.0 , Book 2 Annex A2.1- Recovery Function Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data computed by LT is good Issuer Public Key Certificate is good ICC public Certificate is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 200

Test No. 2CC.080.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Trailer recovered from the Signed Dynamic Application Data does not equal BC. Reference: 2RC.072.0 , Book 2 - Section 6.5.2 - Recover Data Trailer not equal to BC Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data is calculated by LT with a Data Trailer different from BC CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 201

Test No. 2CC.081.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Data Header recovered from the Signed Dynamic Application Data does not equal 6A. Reference: 2RC.073.0 , Book 2 - Section 6.5.2 - Recover Data Header not equal to 6A Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data is calculated by LT with a Data Header different from 6A CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 202

Test No. 2CC.082.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the Certificate Format recovered from Signed Dynamic Application Data does not equal 05. Reference: 2RC.074.0 , Book 2 - Section 6.5.2 - Certificate Format not equal to 05 Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data is calculated by LT with a Certificate Format different from 05 CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 203
Test No. 2CC.083.00 Objective: To ensure that the terminal fails the Dynamic Data Authentication, if the calculated Hash Result is different from the Hash Result recovered from the Signed Dynamic Application Data. Reference: 2RC.075.0 , Book 2 - Section 6.5.2 - Difference between calculated Hash Result and recovered Hash Result Conditions: Terminal and LT support Dynamic Data Authentication Signed Dynamic Application Data is calculated by LT with a bad Hash value CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 204
2CC.084.00 Dynamic Data Authentication is OK

Test No. 2CC.084.00 Objective: To ensure that if all the step described in Book 2 - Section 6.5 are OK, the terminal succeeds the Dynamic Data Authentication. Reference: 2RC.076.0 , Book 2 - Section6.5.2 - Dynamic Data Authentication is OK Conditions: Dynamic signature computed by LT is good Terminal and LT support Dynamic Data Authentication CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 205
2CC.085.00 SDA Tag List in Dynamic Data Authentication

Test No. 2CC.085.00 Objective: To ensure that the terminal checks that SDA Tag List contains only AIP in DDA Reference: 2RC.085.0, Book 2 - Section 6.4 - Static Data Authenticated Tag Conditions: ICC and Terminal support DDA CDOL1 requests also TSI and TVR SDA Tag List contains AFL Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline DDA failed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 206
2CC.086.00 ICC Dynamic Number Stored

Test No. 2CC.086.00 Objective: To ensure that the terminal stores the ICC Dynamic Number in Tag '9F 4C' Reference: 2RC.086.0, Book 2 - Section 6.5.2 - ICC Dynamic Number Stored Conditions: ICC and Terminal support DDA CDOL1 requests also TSI, TVR and Tag '9F 4C'
Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline DDA succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed Value of Tag '9F 4C' shall be the same as used in DDA
Page 207
2CC.091.00 Key used for PIN Encryption/Decryption

Test No. 2CC.091.00 Objective: To ensure that if the terminal supports offline PIN encryption, it is able to use a PIN encipherment public key stored in the card to encrypt the PIN and present it to the card. Reference: 2RC.083.0 , Book 2 - Section 7- Key used for PIN Encryption/Decryption Conditions: Terminal and LT support Offline PIN encryption PIN Encipherment Public Key and associated data is present in LT CVM requires 'Enciphered PIN verification Offline' CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. Once deciphered with PIN encipherment private Key, the LT shall recover a the PIN value presented within the PIN block and the unpredictable Number generated by LT TSI byte 1, bit 7=1 ie Cardholder verification was performed TVR byte 3, bit 8=0 ie Cardholder verification was successful
Page 208
2CC.094.00 Random behaviour of PIN Encipherment padding pattern

Test No. 2CC.094.00 Objective: To ensure that if the terminal supports offline PIN encryption, it is able to generate a RANDOM pattern of N-17 bytes. Reference: 2RC.096.0, Book 2 - Section 7.2 - Random Padding Pattern Conditions: Terminal and LT support Offline PIN encryption PIN Encipherment Public Key and associated data is present in LT CVM requires 'Enciphered PIN verification Offline' CDOL1 requests TSI and TVR Procedure: Several transactions are processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. Once deciphered with PIN encipherment private Key, the LT shall recover the PIN value presented within the PIN block and the unpredictable Number generated by LT The tester shall check the "random behaviour" of the padding pattern comparing values from different transactions. TVR byte 3, bit 8=0 ie Cardholder verification was successful TSI byte 1, bit 7=1 ie Cardholder verification was performed
Page 209
2CC.095.00 Value of ICC PIN Encryption Public Key Exponent

Test No. 2CC.095.00 Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent for ICC PIN Encipherment Public Key for PIN encryption Reference: 2RC.087.0 , Book 2 - Section 7.1 - Value of ICC PIN Encryption Public Key Exponent Conditions: Terminal and LT support Offline PIN encryption PIN Encipherment Public Key and associated data is present in LT CVM requires 'Enciphered PIN verification Offline' Exponent of ICC PIN Encipherment Public Key is 3 or 216 + 1 (2 values tested) Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion Once deciphered with PIN encipherment private Key, the LT shall recover the PIN value presented and unpredictable Number generated by LT
Page 210
2CC.096.00 ICC PIN Encipherment Public Key recovering: ICC PIN Encipherment Public Key
Test No. 2CC.096.00 Objective: To ensure that if the terminal supports offline PIN encryption, it is able to retrieve the ICC PIN encipherment Public Key if data in table 20, Book 2 is present in the card. Reference: 2RC.089.0 , Book 2 - Section 7.1 - ICC PIN Encipherment Public Key recovering: ICC PIN Encipherment Public Key Conditions: Terminal and LT support Offline PIN encryption PIN Encipherment Public Key and associated data are present in LT Data in table 20, Book 2 - Section 7.1 is present in the LT. CVM requires 'Enciphered PIN verification Offline' Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. Once deciphered with PIN encipherment private Key, the LT shall recover the PIN value presented and unpredictable Number generated by LT
Page 211
2CC.097.00 ICC PIN Encipherment Public Key recovery: ICC Issuer Public Key
Test No. 2CC.097.00 Objective: To ensure that if the terminal supports offline PIN encryption, it is able to retrieve the ICC Public Key if data in table 20, Book 2, is not present in the card, but all data elements in table 8, Book 2, are present in the ICC, if ICC 16 Public Key Exponent is = 3 or 2 +1. Reference: 2RC.090.0 , Book 2 - Section 7.1 - ICC PIN Encipherment Public Key recovering ICC Issuer Public Key Conditions: Terminal and LT support Offline PIN encryption ICC Public Key and associated data are present in LT Data in table 20, Book 2 is not present in the LT , but all data elements in table 11, Book 2 are present in the LT, if the ICC Public Key Exponent is = 3 or 216 +1. CVM requires 'Enciphered PIN verification Offline' CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. Once deciphered with ICC private Key, the LT shall recover the PIN value presented within the PIN block and the unpredictable Number generated by LT TSI byte 1, bit 7=1 ie Cardholder verification was performed TVR byte 3, bit 8=0 ie Cardholder verification was successful
Page 212
2CC.098.00 ICC PIN Encipherment Public Key recovering failed

Test No. 2CC.098.00 Objective: To ensure that if the terminal supports offline PIN encryption, and if it is not able to retrieve the ICC PIN encipherment Public Key or ICC Public Key, the terminal fails the PIN encryption Reference: 2RC.091.0 , Book 2 - Section 7.1 - ICC PIN Encipherment Public Key recovering failed Conditions: Terminal and LT support Offline PIN encryption PIN Encipherment Public Key Certificate is not good in LT CVM requires 'Enciphered PIN verification Offline' CDOL1 requests TSI and TVR
Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful
Page 213
2CC.099.00 PIN Entry

Test No. 2CC.099.00 Objective: To ensure that if the terminal supports offline PIN encryption, it asks the cardholder to enter his PIN on the PIN Pad, and encrypts it before presentation to the card Reference: 2RC.092.0 , Book 2 - Section 7.2 - PIN Entry Conditions: Terminal and LT support Offline PIN encryption ICC Public Key and associated data are present in LT CVM requires 'Enciphered PIN verification Offline' Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. The terminal (PIN Pad) shall asks for PIN entry Once deciphered with PIN encipherment private Key, the LT shall recover the PIN Block on 8 bytes and the PIN entered in plaintext format
Page 214
2CC.100.00 Unpredictable Number

Test No. 2CC.100.00 Objective: To ensure that if the terminal supports offline PIN encryption, it issues a GET CHALLENGE command to obtain an unpredictable Number from the card Reference: 2RC.093.0 , Book 2 - Section 7.2 - Unpredictable Number Conditions: Terminal and LT support Offline PIN encryption ICC Public Key and associated data are present in LT CVM requires 'Enciphered PIN verification Offline' Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. The LT shall receive a GET CHALLENGE command from the terminal
2CC.101.00 Enciphered PIN Data

Test No. 2CC.101.00 Objective: To ensure that if the terminal supports offline PIN encryption, it is able to encrypt the PIN data using the recovery function specified in Book 2 Reference: 2RC.094.0 , Book 2 - Section 7.2 - Enciphered PIN Data Conditions: Terminal and LT support Offline PIN encryption ICC Public Key and associated data are present in LT CVM requires 'Enciphered PIN verification Offline' Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. Once deciphered with PIN encipherment private Key, the LT shall recover a PIN Block on 8 bytes and the PIN entered in plaintext format
Page 215
2CC.102.00 VERIFY
Test No. 2CC.102.00 Objective: To ensure that if the terminal supports offline PIN encryption, it issues a VERIFY command containing the Enciphered PIN Data Reference: 2RC.095.0 , Book 2 - Section 7.2 - VERIFY Conditions: Terminal and LT support Offline PIN encryption ICC Public Key and associated data are present in LT CVM requires 'Enciphered PIN verification Offline' Procedure: Application in LT is selected and transaction is processed with LT (in particular Cardholder verification). Pass Criteria: The terminal shall process the transaction until completion. The LT shall receive a VERIFY command from the terminal with Enciphered PIN Data in the data field
Page 216
2CC.119.00 PDOL in Enhanced Combined DDA/AC

Test No. 2CC.119.00 Objective: To ensure that the terminal can use PDOL in Enhanced Combined DDA/AC Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC PDOL is present in LT Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 217
2CC.120.00 Unpredictable Number (Tag 9F 37) in CDOL1

Test No. 2CC.120.00 Objective: To ensure that the terminal checks the presence of Terminal Unpredictable Number (tag 9F 37) in CDOL1 Reference: Based on Bulletin N 6 Conditions: CDOL1 in LT does not include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC CDOL2 includes TVR, TSI and Unpredictable Number Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 218
2CC.121.00 Unpredictable number (Tag 9F 37) in CDOL2

Test No. 2CC.121.00 Objective: To ensure that the terminal checks the presence of Terminal Unpredictable Number (tag 9F 37) in CDOL2 Reference: Based on Bulletin N 6 Conditions: CDOL1 in LT includes Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC CDOL2 does not include Unpredictable Number First GENERATE AC response from LT is ARQC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 219
2CC.122.00 ICC responds with AAC (1)

Test No. 2CC.122.00 Objective: To ensure that the terminal sets Enhanced Combined DDA/AC failed if LT responds AAC Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT responds AAC at the first generate AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. The transaction shall be declined.
The following pass criteria only applies if the terminal has the ability to store declined transactions: TVR byte 1, bit 3 shall be set to 1 indicating Combined DDA/AC Generation failed.
Page 220
2CC.122.01 ICC responds with AAC (2)

Test No. 2CC.122.01 Objective: To ensure that the terminal sets Enhanced Combined DDA/AC failed if LT responds AAC Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT responds ARQC at the first generate AC LT responds AAC at the second generate AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. The transaction shall be declined.
The following pass criteria only applies if the terminal has the ability to store declined transactions. TVR byte 1, bit 3 shall be set to 1 indicating Combined DDA/AC Generation failed.
Page 221
2CC.123.00 Signed Dynamic Application Data Length

Test No. 2CC.123.00 Objective: To ensure that the terminal compare the Signed Dynamic Application Data length with the ICC Public Key length Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Length of Signed Dynamic Application Data is different from the ICC Public Key length CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 222
2CC.124.00 Recovered Data trailer not equal to BC

Test No. 2CC.124.00 Objective: To ensure that the terminal checks the recovered data trailer Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Data trailer is different from BC CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 223
2CC.125.00 Recovered Data header not equal to 6A

Test No. 2CC.125.00 Objective: To ensure that the terminal checks the recovered data header Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Data header is different from 6A CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 224
2CC.126.00 Recovered Signed Data Format not equal to 05

Test No. 2CC.126.00 Objective: To ensure that the terminal checks the recovered signed data format Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Signed Data Format is different from 05 CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 225
2CC.127.00 Recovered CID different from CID obtained after Generate AC (1)
Test No. 2CC.127.00 Objective: To ensure that the terminal checks that the CID recovered is the same as the one transmitted in the response to the Generate AC Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT responds with TC CID in signature is ARQC CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 226
2CC.127.01 Recovered CID different from CID obtained after Generate AC (2)
Test No. 2CC.127.01 Objective: To ensure that the terminal checks that the CID recovered is the same as the one transmitted in the response to the Generate AC. Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT includes Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT responds with a ARQC CID in signature is TC CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion.
TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 227
2CC.128.00 Compare hash result

Test No. 2CC.128.00 Objective: To ensure that the terminal compares the hash result Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Hash result is corrupted CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 228
2CC.129.00 Compare Transaction Data Hash Code

Test No. 2CC.129.00 Objective: To ensure that the terminal compares the Transaction Data Hash Code Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Transaction Data Hash result is corrupted CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 229
2CC.130.00 Issuer Application Data in Enhanced Combined DDA/AC

Test No. 2CC.130.00 Objective: To ensure that the terminal can use Issuer Application Data in Enhanced Combined DDA/AC Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT includes Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Issuer Application Data is present as response of Generate AC. CDOL2 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 230
2CC.131.00 ICC Dynamic Number is stored

Test No. 2CC.131.00 Objective: To ensure that the terminal stores the ICC Dynamic Number in Tag 9F 4C Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR, TSI and ICC Dynamic Number (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed ICC Dynamic Number stored in Tag 9F 4C is the same as the one used in Enhanced Combined DDA/AC
Page 231
2CC.132.00 Application Cryptogram stored

Test No. 2CC.132.00 Objective: To ensure that the terminal stores the Application Cryptogram in Tag 9F 26 Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT includes Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR, TSI and Application Cryptogram (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed Application Cryptogram stored in Tag 9F 26 is the same as the one used in Enhanced Combined DDA/AC
Page 232
2CC.133.00 Unpredictable Number generated by the terminal

Test No. 2CC.133.00 Objective: To ensure that the terminal generates a random number different from one to another transaction Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC CDOL2 requests TVR and TSI Procedure: Several transactions are processed. The unpredictable number values generated by the terminal will be compared. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed Tag 9F37 is checked and compared with the one from the previous transaction. They shall be different.
Page 233
2CC.135.00 Signed Dynamic Application Data is not present in response to generate AC

Test No. 2CC.135.00 Objective: To ensure that the terminal checks that the data in table 16, Book 2, section 6.6.1 is present. Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT answers an TC Tag 9F4B is not present in response to the Generate AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transactions to completion. The transaction shall be declined
Page 234
2CC.136.00 Values of CDOL1 for Transaction Data hash

Test No. 2CC.136.00 Objective: To ensure that the terminal stores the values of the data elements specified nd by CDOL1 for Enhanced Combined DDA/AC at the 2 Generate AC. Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC CDOL1 and CDOL2 requests TSI and TVR. LT sends an ARQC at 1st Generate AC, Enhanced Combined DDA/AC is st correct at the 1 Generate AC. LT sends a TC at 2nd Generate AC, Enhanced Combined DDA/AC is nd correct at the 2 Generate AC. Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 235
2CC.137.00 Values of PDOL for Transaction Data hash

Test No. 2CC.137.00 Objective: To ensure that the terminal stores the values of the data elements specified nd by PDOL for Enhanced Combined DDA/AC at the 2 Generate AC. Reference: Based on Bulletin N 6 Conditions: CDOL1 and CDOL2 in LT include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT sends an ARQC at 1 Generate AC, Enhanced Combined DDA/AC is st correct at the 1 Generate AC. LT sends a TC at 2nd Generate AC, Enhanced Combined DDA/AC is nd correct at the 2 Generate AC. PDOL is present in LT (Value indicated by PDOL will change between the 1st and the 2nd Generate AC). Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
st
Page 236
Data Objects
2CE.001.00 Length field: 1 byte
Test No. 2CE.001.00 Objective: To ensure that terminal is able to support Data Object with Length on 1 byte (b8 = 0) Reference: 2RE.001.0 - Book 3 Annex B - Length field Conditions: LT contains Data Objects to be read with length on one byte (PAN for instance) Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion and shall manage correctly the Data Object with length on 1 byte received.
2CE.001.01 Length field: 2 bytes

Test No. 2CE.001.01 Objective: To ensure that terminal is able to support Data Object with Length on 2 bytes (81 xx) Reference: 2RE.001.0 - Book 3 Annex B - Length field Conditions: LT contains Data Object to be read with length on 2 bytes Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion and shall manage correctly the Data Object with length on 2 bytes received.
Page 237
2CE.001.02 Length field: 3 bytes

Test No. 2CE.001.02 Objective: To ensure that terminal is able to support Data Object with Length on 3 bytes (82 xx xx) Reference: 2RE.001.0 - Book 3 Annex B - Length field Conditions: LT contains Data Object to be read with length on 3 bytes Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion and shall manage correctly the Data Object with length on 3 bytes received.
Page 238
Security Mechanisms
2CG.002.00 Signature verification
Test No. 2CG.002.00 Objective: To ensure that the terminal verifies signature as described in Book 2 Annex A 2.1 Reference: 2RG.002.0 - Book 2 Annex A - Signature verification Conditions: Issuer Public Key Certificate and Static signature in LT are good Terminal and LT support Static Data Authentication CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded
Page 239
Approved Cryptographic Algorithms

2CH.001.00 The Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys
Test No. 2CH.001.00 Objective: To ensure that if terminal supports the Dynamic Data Authentication (respectively Static Data Authentication) , it supports Public key Moduli with length verifying NIC NI NCA (respectively NI NCA ). Reference: 2RH.001.0 - Book 2 Annex B2 Section 1 - The Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys Conditions: Terminal supports either Dynamic or Static Data Authentication 2 tests are performed: 1. LT supports Dynamic Data Authentication , NIC NI NCA , Dynamic signature computed by LT is good 2. LT supports Static Data Authentication , NI NCA , Static signature in LT is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic or Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 or bit 7 =0 ie Offline Dynamic or Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 240
2CH.002.00 Coding the Public Key Algorithm Indicator

Test No. 2CH.002.00 Objective: To ensure that the terminal supports Issuer Public Key Algorithm value equal to 01 Reference: 2RH.003.0 - Book 2 Annex B2 Section 1 - Coding the Public Key Algorithm Indicator Conditions: Issuer Public Key Certificate in LT is calculated with Issuer Public Key Algorithm value equal to 01 Terminal and LT support Static Data Authentication CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded
Page 241
2CH.003.00 Upper bound for size of moduli

Test No. 2CH.003.00 Objective: To ensure that if terminal supports the Dynamic Data Authentication (respectively Static Data Authentication) , it supports Public key Moduli with maximum length as defined below max NIC length is 248 bytes max NI length is 248 bytes max NCA length is 248 bytes EMVCo. will be testing the NCA to perform 248 bytes.
Reference: 2RH.004.0 - Book 2 Annex B2 Section 1 - Upper bound for size of moduli Conditions: Terminal supports either Dynamic or Static Data Authentication 2 tests are performed: 1. LT supports Dynamic Data Authentication , length NIC = 248 bytes, length NI = 248 bytes, length NCA = 248 bytes, Dynamic signature computed by LT is good 2. LT supports Static Data Authentication , length NI = 248 bytes, length NCA = 248 bytes, Static signature in LT is good CDOL1 requests TSI and TVR
Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic or Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 or bit 7 =0 ie Offline Dynamic or Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 242
2CH.010.00 Coding of Hash Algorithm Indicator

Test No. 2CH.010.00 Objective: To ensure that the terminal supports Hash Algorithm Indicator value equal to 01 Reference: 2RH.011.0 - Book 2 Annex B3 Section 1 - Coding of Hash Algorithm Indicator Conditions: Issuer Public Key Certificate in LT is calculated with Hash Algorithm Indicator value equal to 01 Terminal and LT support Static Data Authentication CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded
Page 243
ICC Application Specification System, Test Case Description
for
Payment
Files for Financial Transaction Interchange

2CI.001.00 READ RECORD with the Short File Identifiers (SFI) ranged from 1 to 10
Test No. 2CI.001.00 Objective: To ensure that the terminal is able to read data in file with SFI in range 1 to 10 (0x01 to 0x0A) using READ RECORD command Reference: 2RI.001.0 - Book 3 Section 3 - READ RECORD with the Short File Identifiers (SFI) ranged from 1 to 10 Conditions: One Mandatory Data Element (PAN for instance) is located in file with SFI in range 01 to 10 (test is made with all values in range) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
Page 244
2CI.002.00
Test No. 2CI.002.00
READ RECORD in linear files
Objective: To ensure that the terminal is able to read data in file with linear structure and records with fix size or variable size using READ RECORD command Reference: 2RI.002.0 - Book 3 Section 3 - READ RECORD in linear files Conditions: One Mandatory Data Element (PAN for instance) is located in file with linear structure and records with fix size Another Mandatory Data Element (Expiration Date for Instance) is located in file with linear structure and records with variable size Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
2CI.003.00 records
Test No. 2CI.003.00
READ RECORD in files containing multiple
Objective: To ensure that the terminal is able to read data in file with several records using READ RECORD command Reference: 2RI.003.0 - Book 3 Section 3 - READ RECORD in files containing multiple records Conditions: One Mandatory Data Element (PAN for instance) is located in first record of a file Another Mandatory Data Element (Expiration Date for Instance) is located in second record of same file Another Mandatory Data Element (CDOL1 and CDOL2 for Instance) is located in third record of same file Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
Page 245
2CI.004.00 READ RECORD with the record size in the range from 1 to 254 bytes
Test No. 2CI.004.00 Objective: To ensure that the terminal is able to read data in file with record size in range from 1 to 254 bytes using READ RECORD command Reference: 2RI.004.0 - Book 3 Section 3 - READ RECORD with the record size in the range from 1 to 254 bytes Conditions: A record containing only the template and length equals to 00 (70 00) is located in a single record A Data Element with average length is located in a single record (for instance Signed Static Application Data or CDOL1) A Data Element with maximum length (Total length including Tag and Length and Template is 254) is located in a single record (for instance CDOL1) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
2CI.005.00
Test No. 2CI.005.00
Record Data Format
Objective: To ensure that the terminal is able to extract data read in record from template 0x70. Reference: 2RI.005.0 - Book 3 Section 3 - Record Data Format Conditions: Mandatory Data Elements (PAN, Expiration Date, CDOL1 and CDOL2) are located in a record within template 0x70 Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
Page 246
2CI.007.00 Free access conditions for files accessible using the READ RECORD command
Test No. 2CI.007.00 Objective: To ensure that the terminal is able to read data in a file with free access conditions Reference: 2RI.007.0 - Book 3 Section 3 - Free access conditions for files accessible using the READ RECORD command Conditions: Mandatory Data Elements are located in a file with free access conditions Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion.
2CI.008.00
Test No. 2CI.008.00
READ RECORD in the Application File Locator
Objective: To ensure that the terminal is able to interpret the AFL and read data in the card using READ RECORD command according to the AFL information Reference: 2RI.008.0 - Book 3 Section 3 - READ RECORD in the Application File Locator Conditions: AFL bytes 1,2, & 3 are tested in the LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The LT shall receive a sequence of READ RECORD commands according to the AFL
Page 247
2CI.009.00 Date
Test No. 2CI.009.00
Mandatory Data Objects: Application Expiration
Objective: To ensure that the terminal checks that mandatory Data Object Application Expiration Date is present in the card and is able to use it. Reference: 2RI.010.0 - Book 3 Section 3.1 - Mandatory Data Objects: Application Expiration Date Conditions: Application Expiration Date is present in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion
2CI.010.00
Test No. 2CI.010.00
Mandatory Data Objects: PAN
Objective: To ensure that the terminal checks that mandatory Data Object PAN is present in the card and is able to use it. Reference: 2RI.010.1 - Book 3 Section 3.1 - Mandatory Data Objects: PAN Conditions: PAN is present in LT
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion
Page 248
2CI.011.00
Test No. 2CI.011.00
Mandatory Data Objects: CDOL 1
Objective: To ensure that the terminal checks that mandatory Data Object CDOL1 is present in the card and is able to use it. Reference: 2RI.010.2 - Book 3 Section 3.1 - Mandatory Data Objects: CDOL 1 Conditions: CDOL1 is present in LT
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall send the first Generate AC with the data requested in CDOL1
2CI.012.00
Test No. 2CI.012.00
Mandatory Data Objects: CDOL 2
Objective: To ensure that the terminal checks that mandatory Data Object CDOL2 is present in the card and is able to use it. Reference: 2RI.010.3 - Book 3 Section 3.1 - Mandatory Data Objects: CDOL 2 Conditions: CDOL2 is present in LT The LT requests an ARQC at first generate AC
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall send an 2nd Generate AC with the data requested in CDOL2
Page 249
2CI.013.00
Test No. 2CI.013.00
Optional Data Objects:
Objective: To ensure that the terminal accepts presence or absence of optional Data Object. Reference: 2RI.010.4 - Book 3 Section 3.1 - Optional Data Objects Conditions: Test is made with presence and absence of Optional Data Objects: (All Data Objects coming from card and read with READ RECORD except those listed in Book 3 table II-2, table II-3, table II-4.
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion
Page 250
2CI.014.00 Mandatory Data Objects for Offline Static Data Authentication

Test No. 2CI.014.00 Objective: To ensure that the terminal checks that if supported, mandatory Data Objects for Offline Static Data Authentication are present in the card and it is able to use them. Reference: 2RI.011.0 - Book 3 Section 3.1 - Mandatory Data Objects for Offline Static Data Authentication Conditions: Terminal and LT support Static Data Authentication Certification Authority Public Key Index is present in LT Issuer Public Key Certificate is present in LT Signed Static Application Data is present in LT Issuer Public Key Remainder is present in LT (The Issuer Public Key used in this test case shall allow the issuer public Key remainder to be present) Issuer Public Key Exponent is present in LT CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 7 = 0 i.e. Offline Static Data Authentication succeeded TVR byte 1, bit 6 = 0 i.e. No ICC Data missing TSI byte 1 bit 8 = 1 i.e.. Offline Data authentication was performed
Page 251
2CI.015.00 Mandatory Data Objects for Offline Dynamic Data Authentication

Test No. 2CI.015.00 Objective: To ensure that the terminal checks that if supported, mandatory Data Objects for Offline Dynamic Data Authentication are present in the card and it is able to use them. Reference: 2RI.012.0 - Book 3 Section 3.1 - Mandatory Data Objects for Offline Dynamic Data Authentication Conditions: Terminal and LT support Dynamic Data Authentication Certification Authority Public Key Index is present in LT Issuer Public Key Certificate is present in LT Issuer Public Key Remainder is present in LT (The Issuer Public Key used in this test case shall allow the issuer public Key remainder to be present) Issuer Public Key Exponent is present in LT ICC Public Key Certificate is present in LT ICC Public Key Remainder is present in LT (The ICC Public Key is used in this test case shall allow the ICC Public Key remainder to be present) ICC Public Key Exponent is present in LT DDOL present in the LT CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TVR byte 1, bit 6 = 0 ie No ICC Data missing TSI byte 1 bit 8= 1 ie. Offline Data authentication was performed
Page 252
2CI.017.00
Test No. 2CI.017.00
GET DATA on PIN Try Counter
Objective: To ensure that the terminal is able to retrieve the PTC using the GET DATA command Reference: 2RI.014.0 - Book 3 Section 3.2 - GET DATA on PIN Try Counter Conditions: Both terminal and LT support Offline PIN verification Terminal supports GET DATA for PTC
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion LT shall receive a GET DATA command ( 80 CA 9F 17 )
2CI.018.00
Test No. 2CI.018.00
GET DATA on Last Online ATC Register
Objective: To ensure that the terminal is able to retrieve the LOATC using the GET DATA command Reference: 2RI.015.0 - Book 3 Section 3.2 - GET DATA on Last Online ATC Register Conditions: Lower and Upper consecutive Offline limits are present in LT Terminal supports Velocity Checking CDOL1 requests TVR LT supports Terminal Risk Management
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 6 = 0 ie No ICC Data missing LT shall receive a GET DATA command ( 80 CA 9F 13 )
Page 253
2CI.019.00 ICC
Test No. 2CI.019.00
Both the LCOL and UCOL data objects exist in the
Objective: To ensure that the terminal retrieves the ATC using the GET DATA command when Lower and Upper consecutive Offline limits are present in the card Reference: 2RI.016.0 - Book 3 Section 3.2 - Both the Lower and the Upper Consecutive Offline Limit data objects exist in the ICC Conditions: Lower and Upper consecutive Offline limits are present in LT Terminal supports Velocity Checking CDOL1 requests TVR LT supports terminal risk management
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 6 = 0 ie No ICC Data missing LT shall receive a GET DATA command ( 80 CA 9F 36 )
Page 254
2CI.020.00 Either the LCOL or the UCOL data objects is not present in the ICC
Test No. 2CI.020.00 Objective: To ensure that the terminal abort velocity checking when either Lower or Upper consecutive Offline limits are not present in the card Reference: 2RI.017.0 - Book 3 Section 3.2 - Either the Lower or the Upper Consecutive Offline Limit data objects is not present in the ICC Conditions: LT supports terminal risk management Terminal supports velocity checking Either Lower or Upper consecutive Offline limits are not present in LT
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: Terminal will terminate Velocity checking, The terminal shall process the transaction until completion LT shall not receive a GET DATA command for the ATC ( 80 CA 9F 36 ) LT shall not receive a GET DATA command for the LOATC (80 CA 9F 13)
Page 255
2CI.021.00 command
Test No. 2CI.021.00
Data retrievable by GET PROCESSING OPTIONS
Objective: To ensure that the terminal is able to retrieve and understand both AFL and AIP, using the GET PROCESSING OPTIONS Reference: 2RI.018.0 - Book 3 Section 3.3 - Data retrievable by GET PROCESSING OPTIONS command Conditions: AFL and AIP are present in the LT CDOL1 and CDOL2 request TSI and TVR Issuer authentication shall be verified by CDOL2 if terminal has online capability Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion LT shall receive a GET PROCESSING OPTIONS command LT shall receive a sequence of READ RECORD according to AFL TVR, TSI and command received by the LT shall reflect options supported in AIP (Offline Authentication, Cardholder Verification, Terminal Risk Management and Issuer Authentication)
Page 256
2CI.022.00 Functions specified in the AIP: Offline Static Data Authentication

Test No. 2CI.022.00 Objective: To ensure that the terminal performs Offline Static Data Authentication if supported in AIP Reference: 2RI.019.0 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Offline Static Data Authentication Conditions: AIP returned by LT specifies that Offline Static Data Authentication is supported and not Offline Dynamic Data Authentication CDOL1 request TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 8 = 0 ie Offline Data Authentication was performed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 257
2CI.023.00 Functions not specified in the AIP: Offline Static Data Authentication
Test No. 2CI.023.00 Objective: To ensure that the terminal does not perform Offline Static Data Authentication if not supported in AIP Reference: 2RI.019.1 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Offline Static Data Authentication Conditions: AIP returned by LT specifies that Offline Static Data Authentication is not supported and Offline Dynamic Data Authentication neither CDOL1 request TSI and TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 8 = 1 ie Offline Data Authentication was not performed TSI byte 1, bit 8 = 0 ie Offline Data Authentication was not performed
Page 258
2CI.024.00 Functions specified in the AIP: Offline Dynamic Data Authentication

Test No. 2CI.024.00 Objective: To ensure that the terminal performs Offline Dynamic Data Authentication if supported in AIP Reference: 2RI.019.2 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Offline Dynamic Data Authentication Conditions: AIP returned by LT specifies that Offline Dynamic Data Authentication is supported and not Offline Static Data Authentication CDOL1 request TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 8 = 0 ie Offline Data Authentication was performed TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 259
2CI.025.00 Functions not specified in the AIP: Offline Dynamic Data Authentication
Test No. 2CI.025.00 Objective: To ensure that the terminal does not perform Offline Dynamic Data Authentication if not supported in AIP Reference: 2RI.019.3 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Offline Dynamic Data Authentication Conditions: AIP returned by LT specifies that Offline Dynamic Data Authentication is not supported and Offline Static Data Authentication neither CDOL1 request TSI and TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 8 = 1 ie Offline Data Authentication was not performed TSI byte 1, bit 8 = 0 ie Offline Data Authentication was not performed
Page 260
2CI.026.00 Functions specified in the AIP: Cardholder verification

Test No. 2CI.026.00 Objective: To ensure that the terminal performs Cardholder Verification if supported in AIP Reference: 2RI.019.4 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Cardholder verification Conditions: AIP returned by LT specifies that Cardholder Verification is supported CVM indicates Fail CVM, always CDOL1 request TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8=1 ie Cardholder verification was not successful TSI byte 1, bit 7 = 1 ie Cardholder Verification was performed
Page 261
2CI.027.00 Functions not specified in the AIP: Cardholder verification

Test No. 2CI.027.00 Objective: To ensure that the terminal does not perform Cardholder Verification if not supported in AIP Reference: 2RI.019.5 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Cardholder verification Conditions: AIP returned by LT specifies that Cardholder Verification is not supported CVM is present in LT and indicates Fail CVM, always CDOL1 requests TSI and TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder Verification was not failed TSI byte 1, bit 7 = 0 ie Cardholder Verification was not performed
Page 262
2CI.028.00 Functions specified in the AIP: Terminal Risk Management

Test No. 2CI.028.00 Objective: To ensure that the terminal performs Terminal Risk Management if supported in AIP Reference: 2RI.019.6 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Terminal Risk Management Conditions: Terminal supports Velocity checking AIP returned by LT specifies that Terminal Risk Management is supported UCOL and LCOL exist in the LT Last Online ATC is set to 0 in LT CDOL1 request TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 2, bit 4 = 1 ie New Card TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 263
2CI.029.00 Functions not specified in the AIP: Terminal Risk Management

Test No. 2CI.029.00 Objective: To ensure that the terminal does not perform Terminal Risk Management if not supported in AIP Reference: 2RI.019.7 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Terminal Risk Management Conditions: AIP returned by LT specifies that Terminal Risk Management is not supported UCOL and LCOL exists in the LT with 0 value CDOL1 request TSI and TVR Transaction amount above Terminal Floor Limit Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion TVR byte 2, bit 4 = 0 ie not New Card TVR byte 4, bit 8=0 ie Transaction Floor Limit not exceeded TVR byte 4, bit 7=0 ie Lower Consecutive Offline Limit not exceeded TVR byte 4, bit 6=0 ie Upper Consecutive Offline Limit not exceeded
TVR byte 4, bit 5=0 ie Transaction not selected randomly TSI byte 1, bit 4 = 0 ie Terminal Risk Management was not performed
Page 264
2CI.030.00 Functions specified in the AIP: Issuer Authentication

Test No. 2CI.030.00 Objective: To ensure that the terminal performs Issuer Authentication if supported in AIP Reference: 2RI.019.8 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Issuer Authentication Conditions: AIP returned by LT specifies that Issuer Authentication is supported Transaction is performed On Line Issuer Authentication Data received in the authorization response message CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion The LT shall receive an EXTERNAL AUTHENTICATE command following the First GENERATE AC TSI byte 1, bit 5 = 1 ie Issuer Authentication was performed
Page 265
2CI.031.00 Functions not specified in the AIP: Issuer Authentication

Test No. 2CI.031.00 Objective: To ensure that the terminal does not perform Issuer Authentication if not supported in AIP Reference: 2RI.019.9 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Issuer Authentication Conditions: AIP returned by LT specifies that Issuer Authentication is not supported Transaction is performed On Line Issuer Authentication Data received in the authorization response message CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion The LT shall not receive an EXTERNAL AUTHENTICATE command following the First GENERATE AC TSI byte 1, bit 5 = 0 ie Issuer Authentication was not performed
Page 266
2CI.032.00
Test No. 2CI.032.00
Exception Handling
Objective: To ensure that the terminal terminates the transaction in case of status returned by the card different from 90 00, 63 Cx, 62 83 unless otherwise specified in Book 3. Reference: 2RI.020.0 - Book 3 Section 4.1 - Exception Handling Conditions: LT returns status different from 90 00, 63 Cx, 62 83 to command sent by the Terminal. Test is performed with several command and with several status except for the following configurations: SW1SW2 = '6985' at GPO SW1SW2 = '6983' or '6984' or '63Cx' at VERIFY if LT and terminal support Offline PIN SW1SW2 = any error code at GET DATA requesting PTC if LT and terminal support Offline PIN SW1SW2 = any error code at GET DATA requesting ATC and LATC if LT and terminal support Velocity Checking as Terminal Risk management SW1SW2 = 6300 at External Authenticate
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall terminate the transaction
Page 267
2CI.033.00 Functions specified in the Application Interchange Profile: Enhanced Combined DDA / GENERATE AC
Test No. 2CI.033.00 Objective: To ensure that the terminal performs Enhanced Combined DDA / GENERATE AC if supported by the ICC as specified in the Application Interchange Profile. Reference: 2RI.021.0 - Book 3 Section 4 - Functions specified in the Application Interchange Profile: Combined DDA / GENERATE AC Conditions: CDOL1 and CDOL2 in ICC includes Unpredictable Number generated by the terminal (tag 9F 37) AIP indicates that ICC supports Enhanced Combined DDA/AC The terminal supports Enhanced Combined DDA/AC CDOL1 requests also TSI and TVR. ICC responds with a TC or ARQC Procedure: Application in LT is selected and transaction is processed with LT (in particular Combined Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Batch Data Captured message or other) shall have TVR byte 1, bit 3 = 0 ie Offline Enhanced Combined DDA succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 268
2CI.034.00 Functions not specified in the Application Interchange Profile: Enhanced Combined DDA / GENERATE AC
Test No. 2CI.034.00 Objective: To ensure that the terminal does not perform Enhanced Combined DDA / GENERATE AC if not supported by the ICC as specified in the Application Interchange Profile. Reference: 2RI.021.1 - Book 3 Section 4 - Functions not specified in the Application Interchange Profile: Enhanced Combined DDA / GENERATE AC Conditions: CDOL1 and CDOL2 in ICC includes Unpredictable Number generated by the terminal (tag 9F 37) AIP does not indicate that ICC supports Enhanced Combined DDA/AC, neither SDA nor DDA The terminal supports Enhanced Combined DDA/AC CDOL1 requests also TSI ICC responds with a TC or ARQC Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall not ask the ICC to process a combined DDA in 1st Generate AC The terminal shall process the transaction until completion. TVR and TSI (contained in Batch Data Captured message or other) shall have TSI byte 1, bit 8 = 0 ie Offline Data Authentication was not performed
Page 269
Functions used in Transaction Processing

2CJ.001.00 GET PROCESSING OPTIONS command execution
Test No. 2CJ.001.00 Objective: To ensure that the terminal sends the GET PROCESSING OPTIONS command immediately after the application selection function. Reference: 2RJ.001.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONS command execution Conditions: No specific conditions Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command following final selection process.
2CJ.002.00 All bits in TSI and TVR are set to 0b

Test No. 2CJ.002.00 Objective: To ensure that TVR and TSI are set to 0b when the terminal starts the transaction Reference: 2RJ.002.0 - Book 3 Section 6.1 - All bits in TSI and TVR are set to 0b Conditions: PDOL request TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: TSI returned by terminal with GET PROCESSING OPTIONS shall be set to 0b TVR returned by terminal with GET PROCESSING OPTIONS shall be set to 0b
Page 270
2CJ.003.00 GET PROCESSING OPTIONS data field, when PDOL is provided in FCI
Test No. 2CJ.003.00 Objective: To ensure that if PDOL is present in the FCI of selected ADF, the terminal sends the GET PROCESSING OPTIONS command with a data field populated with a constructed data object with a tag of 83, a length field with appropriate length and, a value field of concatenated data elements coded according to the PDOL Reference: 2RJ.003.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONS data field, when PDOL is provided in FCI Conditions: PDOL is sent back by the LT in FCI of selected ADF (test is made with several PDOL values) Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command with a data field containing a data object with Tag 83 and a value field of concatenated data elements coded according to the PDOL
2CJ.004.00 GET PROCESSING OPTIONS data field, when PDOL is not provided in FCI
Test No. 2CJ.004.00 Objective: To ensure that if PDOL is not present in the FCI of selected ADF, the terminal sends the GET PROCESSING OPTIONS command with a data field populated with a constructed data object with a tag of 83, and a length 0 Reference: 2RJ.004.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONS data field, when PDOL is not provided in FCI Conditions: No PDOL is sent back by the LT in FCI of selected ADF Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command with a data field containing a data object with Tag 83 and a length 0
Page 271
2CJ.005.00 Rules for Processing Tags listed in the PDOL (1)

Test No. 2CJ.005.00 Objective: To ensure that if PDOL is present in the FCI of selected ADF and if it contains a Data Element which is not defined in Book 1 Annex A Data Elements or does not have the terminal as source, the terminal sends a GET PROCESSING OPTIONS command with a PDOL with a Data Element with the length specified and a value of all hexadecimal zeroes for the tag previously described Reference: 2RJ.006.0 - Book 3 Section 6.1 - Rules for Processing Tags listed in the PDOL(1) Conditions: PDOL is sent back by the LT in FCI of selected ADF and it contains a Data Element which is not defined in [N1] or does not have the terminal as source Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command with a data field containing a data object with Tag 83 Unknown Data Element in PDOL shall be replaced in template 83 with a Data Element with same length and a value of hexadecimal zeroes
Page 272

Test No. 2CJ.006.00 Objective: To ensure that if PDOL is present in the FCI of selected ADF and if it contains a Data Element which is a constructed Data Object, the terminal sends a GET PROCESSING OPTIONS command with a PDOL with a Data Element with the length specified and a value of all hexadecimal zeroes for the tag previously described Reference: 2RJ.006.1 - Book 3 Section 6.1 - Rules for Processing Tags listed in the PDOL (2) Conditions: PDOL is sent back by the LT in FCI of selected ADF and it contains a Data Element which is a constructed Data Object Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command with a data field containing a data object with Tag 83 Constructed Data Object in PDOL shall be replaced in template 83 with a Data Element with same length and a value of hexadecimal zeroes
Page 273

Test No. 2CJ.007.00 Objective: To ensure that if PDOL is present in the FCI of selected ADF and if it contains a Data Element which cannot be provided by the terminal at the moment, the terminal sends a GET PROCESSING OPTIONS command with a PDOL with a Data Element with the length specified and a value of all hexadecimal zeroes for the tag previously described Reference: 2RJ.007.0 - Book 3 Section 6.1 - Rules for Processing Tags listed in the PDOL (3) Conditions: PDOL is sent back by the LT in FCI of selected ADF and it contains a Data Element which cannot be provided by the terminal at the moment Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a GET PROCESSING OPTIONS command with a data field containing a data object with Tag 83 Data Object in PDOL which cannot be provided at the moment shall be replaced in template 83 with a Data Element with same length and a value of hexadecimal zeroes
Page 274
2CJ.008.00 GET PROCESSING OPTIONS transaction state management

Test No. 2CJ.008.00 Objective: To ensure that if the card returns status 69 85 to the GET PROCESSING OPTIONS command, the terminal switches back to the application selection phase Reference: 2RJ.008.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONS transaction state management Conditions: LT returns status 69 85 to GET PROCESSING OPTIONS command At least 2 applications are mutually supported by LT and Terminal Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: After having sent status 69 85 in response to GET PROCESSING OPTIONS, the LT shall receive SELECT command with data field containing the second AID in the candidate list
2CJ.009.00 READ RECORD command execution

Test No. 2CJ.009.00 Objective: To ensure that the terminal always sends the READ RECORDS commands immediately after the GET PROCESSING OPTIONS command. Reference: 2RJ.009.0 - Book 3 Section 6.2 - READ RECORD command execution Conditions: No specific conditions Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: LT shall receive a sequence of READ RECORD commands immediately after the GET PROCESSING OPTIONS command.
Page 275
2CJ.010.00 READ RECORD on each entry in the AFL

Test No. 2CJ.010.00 Objective: To ensure that the terminal is able to interpret the AFL and send READ RECORD for each record between the starting record Number and the ending record number, inclusively. Reference: 2RJ.011.0 - Book 3 Section 6.2 - READ RECORD on each entry in the AFL Conditions: Several combinations of AFL are tested in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The LT shall receive a sequence of READ RECORD commands according to the AFL
2CJ.011.00 Data objects processing

Test No. 2CJ.011.00 Objective: To ensure that the terminal stores all data element read during the Read Application Data phase Reference: 2RJ.013.0 - Book 3 Section 6.2 - Data objects processing Conditions: Minimum two combination of AFL are tested in LT CDOL1 requests all data Elements read in file referenced in AFL. Except CDOL1 and CDOL2. Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The LT shall receive in the GENERATE AC data field, correct values for data elements stored during the Read Application Data phase
Page 276
2CJ.012.00 Data objects processing (Unrecognized Data Objects)

Test No. 2CJ.012.00 Objective: To ensure that the terminal ignores unrecognized Data Objects read during the Read Application Data phase Reference: 2RJ.013.1 - Book 3 Section 6.2 - Data objects processing (unrecognised Data Objects) Conditions: Records to be read contain non EMV Data Objects Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall accept the card and process the transaction until the end.
Page 277
2CJ.012.01 Non recognized data object participating in offline data authentication

Test No. 2CJ.012.01 Objective: To ensure that the terminal is able to include non recognized data objects in offline data authentication provided that they are read with the READ RECORD command and are located in record participating in offline data authentication according to AFL. Reference: 2RJ.013.2 - Book 3 Section 6.2 - Non recognized data object participating in offline data authentication Conditions: A non EMV Data Object is included in a record listed in the AFL as participating in data authentication Terminal and LT support Static Data Authentication Signed Static Application Data is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 278
2CJ.013.00 Record Data Format: mandatory data: Application Expiration Date

Test No. 2CJ.013.00 Objective: To ensure that the terminal terminates the transaction if the Application Expiration Date is missing Reference: 2RJ.015.0 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data: Application Expiration Date Conditions: Application Expiration Date is missing in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CJ.014.00 Record Data Format: mandatory data: PAN

Test No. 2CJ.014.00 Objective: To ensure that the terminal terminates the transaction if the PAN is missing Reference: 2RJ.015.1 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data: PAN Conditions: PAN is missing in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 279
2CJ.015.00 Record Data Format: mandatory data: CDOL1

Test No. 2CJ.015.00 Objective: To ensure that the terminal terminates the transaction if the CDOL1 is missing Reference: 2RJ.015.2 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data: CDOL1 Conditions: CDOL1 is missing in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CJ.016.00 Record Data Format: mandatory data: CDOL2

Test No. 2CJ.016.00 Objective: To ensure that the terminal terminates the transaction if the CDOL2 is missing Reference: 2RJ.015.3 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data: CDOL2 Conditions: CDOL2 is missing in LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 280
2CJ.017.00 Record Data Format: Unique data objects

Test No. 2CJ.017.00 Objective: To ensure that the terminal terminates the transaction if a Data Object is duplicated Reference: 2RJ.016.0 - Book 3 Section 6.2 - Record Data Format: Unique data objects Conditions: A Data Object is duplicated (test is made for several different Data Objects) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CJ.018.00 Record Data Format: Proprietary data participating in offline data authentication
Test No. 2CJ.018.00 Objective: To ensure that the terminal is able to read and include in Offline data authentication, data objects located in proprietary files provided that proprietary files are readable without conditions by READ RECORD command Reference: 2RJ.016.1 - Book 3 Section 6.2 - Data located in proprietary records Conditions: An EMV Data Object is included in a record, located in a proprietary file, and listed in AFL and included in the data to be signed Terminal and LT support Static Data Authentication Signed Static Application Data is good CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 281
2CJ.020.00 Offline Data Authentication is supported

Test No. 2CJ.020.00 Objective: To ensure that if both the card and the terminal support Offline Data Authentication, the terminal performs Offline Data Authentication at any order after the Read Application Data and before completion of the terminal analysis. Reference: 2RJ.018.0 - Book 3 Section 6.3 - Offline Data Authentication is supported Conditions: Terminal and LT support Static Data Authentication Signed Static Application Data is not good IAC denial byte 1 bit 7 = 1, Offline Static Data Authentication failed CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal issue a first GENERATE AC requesting AAC TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed
Page 282
2CJ.021.00 Both the Terminal and the Card support Enhanced Combined DDA/AC (TC, 1st Generate AC)
Test No. 2CJ.021.00 Objective: To ensure that if both the card and the terminal support Enhanced Combined DDA/AC, the terminal performs Enhanced Combined DDA/AC. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC CDOL1 and CDOL2 include Unpredictable Number generated by the terminal (tag 9F 37) LT answers TC at 1st Generate AC Enhanced Combined DDA/AC Generation signature generated by LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 283
2CJ.021.01 Both the Terminal and the Card support Enhanced nd Combined DDA/AC (TC, 2 Generate AC)
Test No. 2CJ.021.01 Objective: To ensure that if both the card and the terminal support Enhanced Combined DDA/AC, the terminal performs Enhanced Combined DDA/AC. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC CDOL1 and CDOL2 include Unpredictable Number generated by the terminal (tag 9F 37) LT answers ARQC at 1st Generate AC and TC at 2nd Generate AC Enhanced Combined DDA/AC Generation signature generated by LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 284
2CJ.021.02 Both the Terminal and the Card support Enhanced Combined DDA/AC (ARQC)
Test No. 2CJ.021.02 Objective: To ensure that if both the card and the terminal support Enhanced Combined DDA/AC, the terminal performs Enhanced Combined DDA/AC. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC CDOL1 and CDOL2 include Unpredictable Number generated by the terminal (tag 9F 37) LT answers ARQC at 1st Generate AC Enhanced Combined DDA/AC Generation signature generated by LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 0 i.e. Combined DDA/AC Generation succeeded TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 285
2CJ.022.00 Both the Terminal and the Card support Offline SDA
Test No. 2CJ.022.00 Objective: To ensure that if both the card and the terminal support Offline Static Data Authentication, and either terminal or card does not support Offline Dynamic Data Authentication, and either the card or terminal (or both) does not support Enhanced Combined DDA/AC Generation, the terminal performs Offline Static Data Authentication. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Static Data Authentication LT and/or Terminal do not support DDA LT and/or Terminal do not support Enhanced Combined DDA/AC Static signature in LT is not good CDOL1 request TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 i.e. Offline Static Data Authentication failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 286
2CJ.023.00 Both the Offline DDA and the Offline SDA are supported
Test No. 2CJ.023.00 Objective: To ensure that if both the card and the terminal support Offline Static Data Authentication, and Offline Dynamic Data Authentication, and either the card or terminal (or both) does not support Enhanced Combined DDA/AC Generation, the terminal performs only Offline Dynamic Data Authentication. Reference: Based on Bulletin N 6 Conditions: Terminal and LT supports Static Data Authentication Terminal and LT supports Dynamic Data Authentication Dynamic signature generated by LT is not good Issuer Public Key Certificate in LT is not good LT and/or Terminal do not support Enhanced Combined DDA/AC CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 i.e. Offline Static Data Authentication was not failed TVR byte 1, bit 4 = 1 i.e. Offline Dynamic Data Authentication failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed
Page 287
2CJ.024.00 Neither the Offline DDA nor the Offline SDA nor the Enhanced Combined DDA/AC is performed
Test No. 2CJ.024.00 Objective: To ensure that if neither Offline Static Data Authentication, or Offline Dynamic Data Authentication or the Enhanced Combined DDA/AC Generation is performed, the terminal sets the Offline data authentication was not performed bit in the TVR to 1b. Reference: Based on Bulletin N 6 Conditions: LT and/or Terminal do not support Static Data Authentication LT and/or Terminal do not support Dynamic Data Authentication LT and/or Terminal do not support Enhanced Combined DDA/AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 8 = 1 i.e. Offline Data Authentication not performed TSI byte 1, bit 8=0 i.e. Offline data authentication was not performed.
Page 288
2CJ.025.00 Rules for Processing the Input Data

Test No. 2CJ.025.00 Objective: To ensure that if Offline Static Data Authentication is performed, the terminal concatenate the data retrieved from the records identified by the AFL, with the data from the Static Data Authentication Tag List and uses the concatenation as an input to the string to be signed Reference: 2RJ.023.0 - Book 3 Section 6.3 - Rules for Processing the Input Data Conditions: LT supports Static Data Authentication AFL indicates data to be included in Static Signature LT contains a Static Data Authentication Tag List CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 289
2CJ.026.00 Rules for Processing the records identified by the AFL, when the Offline DDA is performed (1)
Test No. 2CJ.026.00 Objective: To ensure that when terminal performs Dynamic Data Authentication and builds the string to be signed, the terminal does not include tag 70 and length for records referenced in AFL as participating in Dynamic Data Authentication and located in files with SFI in range 1 to 10 Reference: 2RJ.025.0 - Book 3 Section 6.3 - Rules for Processing the records identified by the AFL, when the Offline DDA is performed (1) Conditions: LT and terminal support Dynamic Data Authentication CDOL1 requests TSI and TVR some records participating in Dynamic Data Authentication are located in file with SFI in range 1 to 10 Dynamic signature generated by the LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 290
2CJ.027.00 Rules for Processing the records identified by the AFL, when the Offline DDA is performed (2)
Test No. 2CJ.027.00 Objective: To ensure that when terminal performs Dynamic Data Authentication and builds the string to be signed, the terminal includes all data of records referenced in AFL as participating in Dynamic Data Authentication and located in files with SFI in range 11 to 30. Reference: 2RJ.026.0 - Book 3 Section 6.3 - Rules for Processing the records identified by the AFL, when the Offline DDA is performed (2) Conditions: LT and terminal support Dynamic Data Authentication CDOL1 requests TSI and TVR some records participating in Dynamic Data Authentication are located in file with SFI in range 11 to 30 Dynamic signature generated by the LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 0 ie Offline Dynamic Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 291
2CJ.028.00 Rules for Processing the records identified by the AFL, when the Offline SDA is performed (1)
Test No. 2CJ.028.00 Objective: To ensure that when terminal performs Static Data Authentication and builds the string to be signed, the terminal does not include tag 70 and length for records referenced in AFL as participating in Static Data Authentication and located in files with SFI in range 1 to 10 Reference: 2RJ.028.0 - Book 3 Section 6.3 - Rules for Processing the records identified by the AFL, when the Offline SDA is performed (1) Conditions: LT and terminal support Static Data Authentication CDOL1 requests TSI and TVR some records participating in Static Data Authentication are located in file with SFI in range 1 to 10 Static signature in the LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 292
2CJ.029.00 Rules for Processing the records identified by the AFL, when the Offline SDA is performed (2)
Test No. 2CJ.029.00 Objective: To ensure that when terminal performs Static Data Authentication and builds the string to be signed, the terminal includes all data of records referenced in AFL as participating in Static Data Authentication and located in files with SFI in range 11 to 30 Reference: 2RJ.029.0 - Book 3 Section 6.3 - Rules for Processing the records identified by the AFL, when the Offline SDA is performed (2) Conditions: LT and terminal support Static Data Authentication CDOL1 requests TSI and TVR some records participating in Static Data Authentication are located in file with SFI in range 11 to 30 Static signature in the LT is good Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 0 ie Offline Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 293
2CJ.032.00 Offline Static Data Authentication fails

Test No. 2CJ.032.00 Objective: To ensure that the terminal set the Offline Static Data Authentication failed bit in the TVR to 1b, if the Static Data Authentication is performed but unsuccessful Reference: 2RJ.032.0 - Book 3 Section 6.3 - Offline Static Data Authentication fails Conditions: Signed Static Application Data in LT is not good Terminal and LT support Static Data Authentication CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 7 = 1 ie Offline Static Data Authentication failed
Page 294
2CJ.033.00 Offline Dynamic Data Authentication fails

Test No. 2CJ.033.00 Objective: To ensure that the terminal set the Offline Dynamic Data Authentication failed bit in the TVR to 1b if the Dynamic Data Authentication is performed but unsuccessful Reference: 2RJ.033.0 - Book 3 Section 6.3 - Offline Dynamic Data Authentication fails Conditions: Data signature returned by the LT is not good Terminal and LT support Dynamic Data Authentication CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 4 = 1 ie Offline Dynamic Data Authentication failed
Page 295
2CJ.033.05 Enhanced Combined DDA/AC fails

Test No. 2CJ.033.05 Objective: To ensure that the terminal sets the Combined DDA/AC Generation failed bit in the TVR to 1b if the Enhanced Combined DDA/AC Generation is performed but unsuccessful Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC Enhanced Combined DDA/AC signature generated in LT is failed CDOL1 and CDOL2 include Unpredictable Number generated by the terminal (tag 9F 37) Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall process the transaction until completion. TVR and TSI (contained in Financial Confirmation message or Batch Data Captured message or other) shall have: TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8=1 i.e. Offline data authentication was performed.
Page 296
2CJ.034.00 Set relevant bit in TSI, upon completion of the Offline Data Authentication
Test No. 2CJ.034.00 Objective: To ensure that the terminal sets the Offline data authentication was performed bit in the TSI to 1b upon completion of the Offline Data Authentication Reference: 2RJ.034.0 - Book 3 Section 6.3 - Set relevant bit in TSI, upon completion of the Offline Data Authentication Conditions: LT and terminal support Static Data Authentication CDOL1 requests TSI and TVR Signed Static Application Data in LT is not good Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed TVR byte 1, bit 7=1 ie Offline static data authentication failed
Page 297
2CJ.035.00 Processing Restrictions function execution

Test No. 2CJ.035.00 Objective: To ensure that the terminal performs processing restrictions functions at any time after Read Application Data and before completion of the terminal action analysis. Reference: 2RJ.035.0 - Book 3 Section 6.4 - Processing Restrictions function execution Conditions: Application Version Number is different in LT and Terminal Issuer Country Code matches Terminal Country Code Transaction is not valid for domestic in AUC Application Expiration Date in the LT has expired CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 8 = 1 ie ICC and Terminal have different application versions TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product TVR byte 2, bit 7 = 1 ie Expired application
Page 298
2CJ.036.00 Application Version Number assigned by the payment system

Test No. 2CJ.036.00 Objective: To ensure that the terminal maintains an Application Version Number assigned by the payment system. Reference: 2RJ.036.0 - Book 3 Section 6.4.1 - Application Version Number assigned by the payment system Conditions: CDOL1 requests Application Version Number (9F 09) Test is made for all applications supported by the terminal Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. LT shall received the value of application version number for the selected application
Page 299
2CJ.037.00 Application Version Number is not present in the ICC

Test No. 2CJ.037.00 Objective: To ensure that the terminal continues the processing of the transaction until the end if Application Version Number is not present in the ICC. Reference: 2RJ.038.0 - Book 3 Section 6.4.1 - Application Version Number is not present in the ICC Conditions: Application Version Number is not present in the ICC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. The terminal shall presume applications are compatible between ICC and terminal TVR byte 2, bit 8 = 0 ie ICC and terminal does not have different application versions
Page 300
2CJ.039.00 Application Version Number present in the ICC and in the terminal are the same (implied)
Test No. 2CJ.039.00 Objective: To ensure that the terminal does not set the ICC and terminal have different application versions bit in the TVR to 1b if the Application Version Number present in the ICC and in the terminal are the same. Reference: 2RJ.039.1 - Book 3 Section 6.4.1 - Application Version Number present in the ICC and in the terminal are the same (implied) Conditions: LT and terminal have the same Application Version Number CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 8 = 0 ie ICC and terminal have the same application versions
Page 301
2CJ.041.00 AUC is present in the ICC and Transaction is conducted at an ATM

Test No. 2CJ.041.00 Objective: To ensure that if the terminal is an ATM and the AUC is present in the card, and the Valid at ATMs bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.042.0 - Book 3 Section 6.4.2 - AUC is present in the ICC and Transaction is conducted at an ATM Conditions: AUC is present in LT Terminal Type is ATM Valid at ATMs bit is not set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product
Page 302
2CJ.042.00 AUC is present in the ICC and Transaction is conducted at an ATM (implied)
Test No. 2CJ.042.00 Objective: To ensure that if the terminal is an ATM and the AUC is present in the card, and the Valid at ATMs bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b Reference: 2RJ.042.1 - Book 3 Section 6.4.2 - AUC is present in the ICC and Transaction is conducted at an ATM (implied) Conditions: AUC is present in LT Terminal Type is ATM Valid at ATMs bit is set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 303
2CJ.043.00 AUC is present in the ICC and Transaction is not conducted at an ATM
Test No. 2CJ.043.00 Objective: To ensure that if the terminal is not an ATM and the AUC is present in the card, and the Valid at terminals other than ATMs bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.043.0 - Book 3 Section 6.4.2 - AUC is present in the ICC and Transaction is not conducted at an ATM Conditions: AUC is present in LT Terminal Type is not an ATM Valid at terminals other than ATMs bit is not set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product
Page 304
2CJ.044.00 AUC is present in the ICC and Transaction is not conducted at an ATM (implied)
Test No. 2CJ.044.00 Objective: To ensure that if the terminal is not an ATM and the AUC is present in the card, and the Valid at terminals other than ATMs bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.043.1 - Book 3 Section 6.4.2 - AUC is present in the ICC and Transaction is not conducted at an ATM (implied) Conditions: AUC is present in LT Terminal Type is not an ATM Valid at terminals other than ATMs bit is set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 305
2CJ.045.00 Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code
Test No. 2CJ.045.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a cash transaction and the AUC is present in the card, and the Valid for domestic cash transactions bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.045.0 - Book 3 Section 6.4.2 - Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code Conditions: Transaction is a cash transaction AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic cash transactions bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a cash transaction
Page 306
2CJ.046.00 Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code (implied)
Test No. 2CJ.046.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a cash transaction and the AUC is present in the card, and the Valid for domestic cash transactions bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.045.1 - Book 3 Section 6.4.2 - Transaction type is a Cash transaction, and Issuer Country Code = Terminal Country Code (implied) Conditions: Transaction is a cash transaction AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic cash transactions bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a cash transaction
Page 307
2CJ.047.00 Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code
Test No. 2CJ.047.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a cash transaction and the AUC is present in the card, and the Valid for international cash transactions bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.046.0 - Book 3 Section 6.4.2 - Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code Conditions: Transaction is a cash transaction AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international cash transactions bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a cash transaction
Page 308
2CJ.048.00 Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code (implied)
Test No. 2CJ.048.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a cash transaction and the AUC is present in the card, and the Valid for international cash transactions bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.046.1 - Book 3 Section 6.4.2 - Transaction type is a Cash transaction, and Issuer Country Code differs from Terminal Country Code (implied) Conditions: Transaction is a cash transaction AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international cash transactions bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a cash transaction
Page 309
2CJ.049.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code
Test No. 2CJ.049.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a purchase of goods and the AUC is present in the card, and the Valid for domestic goods bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.047.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code Conditions: Transaction is a purchase of goods AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic goods bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a purchase of goods
Page 310
2CJ.050.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code (implied)
Test No. 2CJ.050.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a purchase of goods and the AUC is present in the card, and the Valid for domestic goods bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.047.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase of goods, and Issuer Country Code = Terminal Country Code (implied) Conditions: Transaction is a purchase of goods AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic goods bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a purchase of goods
Page 311
2CJ.051.00 Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code
Test No. 2CJ.051.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a purchase of goods and the AUC is present in the card, and the Valid for international goods bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.048.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code Conditions: Transaction is a purchase of goods AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international goods bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a purchase of goods
Page 312
2CJ.052.00 Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code (implied)
Test No. 2CJ.052.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a purchase of goods and the AUC is present in the card, and the Valid for international goods bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.048.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase of goods, and Issuer Country Code differs from Terminal Country Code (implied) Conditions: Transaction is a purchase of goods AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international goods bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a purchase of goods
Page 313
2CJ.053.00 Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code
Test No. 2CJ.053.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a purchase of services and the AUC is present in the card, and the Valid for domestic services bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.049.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code Conditions: Transaction is a purchase of services AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic services bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a purchase of services
Page 314
2CJ.054.00 Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code (implied)
Test No. 2CJ.054.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction Type indicates a purchase of services and the AUC is present in the card, and the Valid for domestic services bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.049.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase of services, and Issuer Country Code = Terminal Country Code (implied) Conditions: Transaction is a purchase of services AUC is present in LT Issuer Country Code matches Terminal Country Code Valid for domestic services bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a purchase of services
Page 315
2CJ.055.00 Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code
Test No. 2CJ.055.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a purchase of services and the AUC is present in the card, and the Valid for international services bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.050.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code Conditions: Transaction is a purchase of services AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international services bit is not set to 1b in the AUC CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product Transaction Type shall indicate a purchase of services
Page 316
2CJ.056.00 Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code (implied)
Test No. 2CJ.056.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction Type indicates a purchase of services and the AUC is present in the card, and the Valid for international services bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.050.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase of services, and Issuer Country Code differs from Terminal Country Code (implied) Conditions: Transaction is a purchase of services AUC is present in LT Issuer Country Code does not match Terminal Country Code Valid for international services bit is set to 1b in the AUC CDOL1 requests TVR and Transaction Type Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product Transaction Type shall indicate a purchase of services
Page 317
2CJ.057.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code
Test No. 2CJ.057.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction has a Cashback amount and the AUC is present in the card, and the Domestic Cashback allowed bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.051.0 - Book 3 Section 6.4.2 - Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code Conditions: Transaction has a cashback amount AUC is present in LT Issuer Country Code matches Terminal Country Code Domestic cashback allowed bit is not set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product
Page 318
2CJ.058.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code (implied)
Test No. 2CJ.058.00 Objective: To ensure that if the Terminal Country Code matches Issuer Country Code and Transaction has a Cashback amount and the AUC is present in the card, and the Domestic cashback allowed bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.051.1 - Book 3 Section 6.4.2 - Transaction has a Cashback amount, and Issuer Country Code = Terminal Country Code (implied) Conditions: Transaction has a cashback amount AUC is present in LT Issuer Country Code matches Terminal Country Code Domestic cashback allowed bit is set to 1b in the AUC Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 319
2CJ.059.00 Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code
Test No. 2CJ.059.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction has a Cashback amount and the AUC is present in the card, and the International cashback allowed bit is not set to 1b in the AUC, the terminal sets the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.052.0 - Book 3 Section 6.4.2 - Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code Conditions: Transaction has a cashback amount AUC is present in LT Issuer Country Code does not match Terminal Country Code International cashback allowed bit is not set to 1b in the AUC CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 1 ie Requested service not allowed for card product
Page 320
2CJ.060.00 Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code (implied)
Test No. 2CJ.060.00 Objective: To ensure that if the Terminal Country Code does not match Issuer Country Code and Transaction has a Cashback amount and the AUC is present in the card, and the International cashback allowed bit is set to 1b in the AUC, the terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.052.1 - Book 3 Section 6.4.2 - Transaction type is a Cashback amount, and Issuer Country Code differs from Terminal Country Code (implied) Conditions: Transaction has a cashback amount AUC is present in LT Issuer Country Code does not match Terminal Country Code International cashback allowed bit is set to 1b in the AUC Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 321
2CJ.061.00 Application Usage Control is not present in the ICC (implied)

Test No. 2CJ.061.00 Objective: To ensure that if the Application Usage control is not present in the ICC, the Terminal does not set the Requested service not allowed for card product bit in the TVR to 1b. Reference: 2RJ.053.0 - Book 3 Section 6.4.2 - Application Usage Control is not present in the ICC implied Conditions: AUC is not present in LT Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 322
2CJ.062.00 Application Usage Control is present in the ICC but not Issuer Country code (implied)
Test No. 2CJ.062.00 Objective: To ensure that if the Application Usage control is present in the ICC but not Issuer Country Code, the Terminal skips the second set of tests described in Book 3 Section 6.4.3. Reference: 2RJ.053.1 - Book 3 Section 6.4.2 - Application Usage Control is present in the ICC but not Issuer Country code (implied) Conditions: AUC is present in LT valid at ATMs and valid at terminals other than ATMs are set in AUC Issuer Country Code is not present in the LT Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 5 = 0 ie Requested service allowed for card product
Page 323
2CJ.063.00 Current Date is less than Application Effective Date

Test No. 2CJ.063.00 Objective: To ensure that the terminal sets to 1b the Application not yet effective bit if the current date is less than the Application Effective Date Reference: 2RJ.055.0 - Book 3 Section 6.4.3 - Current Date is less than Application Effective Date Conditions: Application Effective Date is present in the LT current date is less than the Application Effective Date Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 6 = 1 ie Application not yet effective
Page 324
2CJ.064.00 Current Date is greater than Application Effective Date (implied)

Test No. 2CJ.064.00 Objective: To ensure that the terminal does not set to 1b the Application not yet effective bit if the current date is greater or equal to the Application Effective Date Reference: 2RJ.055.1 - Book 3 Section 6.4.3 - Current Date is greater than Application Effective Date (implied) Conditions: Application Effective Date is present in the LT Current date is greater than the Application Effective Date CDOL1 requested TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 6 = 0 ie Application effective
Page 325
2CJ.064.01 Current Date is equal to Application Effective Date (implied)

Test No. 2CJ.064.01 Objective: To ensure that the terminal does not set to 1b the Application not yet effective bit if the current date is greater or equal to the Application Effective Date Reference: 2RJ.055.2 - Book 3 Section 6.4.3 - Current Date is equal to Application Effective Date (implied) Conditions: Application Effective Date is present in the LT Current data is equal to the Application Effective Date CDOL1 requested TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 6 = 0 ie Application effective
Page 326
2CJ.065.00 Current Date is greater than Application Expiration Date

Test No. 2CJ.065.00 Objective: To ensure that the terminal sets to 1b the expired Application bit if the current date is greater than the Application Expiration Date Reference: 2RJ.056.0 - Book 3 Section 6.4.3 - Current Date is greater than Application Expiration Date Conditions: current date is greater than the Application Expiration Date CDOL1 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 7 = 1 ie expired Application
2CJ.066.00 Current Date is less than Application Expiration Date (implied)

Test No. 2CJ.066.00 Objective: To ensure that the terminal does not set to 1b the expired Application bit if the current date is less or equal to the Application Expiration Date Reference: 2RJ.056.1 - Book 3 Section 6.4.3 - Current Date is less than Application Expiration Date (implied) Conditions: Current date is less than the Application Expiration Date CDOL1 requested TVR to be present Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 7 = 0 ie non expired Application
Page 327
2CJ.066.01 Current Date is equal to the Application Expiration Date (implied)

Test No. 2CJ.066.01 Objective: To ensure that the terminal does not set to 1b the expired Application bit if the current date is less or equal to the Application Expiration Date Reference: 2RJ.056.2 - Book 3 Section 6.4.3 - Current Date is equal to Application Expiration Date (implied) Conditions: Current date is equal to the Application Expiration Date CDOL1 requested TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 7 = 0 ie non expired Application
Page 328
2CJ.067.00 Application Effective Date is not present in the ICC (implied)

Test No. 2CJ.067.00 Objective: To ensure that the terminal does not set to 1b the Application not yet effective bit if the Application Effective Date is not present in ICC Reference: 2RJ.057.0 - Book 3 Section 6.4.3 - Application Effective Date is not present in the ICC (implied) Conditions: Application Effective Date is not present in the LT CDOL1 requests TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 6 = 0 ie Application effective
Page 329
2CJ.068.00 Cardholder Verification is supported in the AIP

Test No. 2CJ.068.00 Objective: To ensure that if the card supports Cardholder verification, the terminal performs Cardholder verification after the Read Application Data and before completion of the terminal analysis Reference: 2RJ.058.0 - Book 3 Section 6.5 - Cardholder Verification is supported in the Application Interchange Profile Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, always' CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = '1' ie Cardholder verification performed
2CJ.069.00 Supported CVR condition: Always

Test No. 2CJ.069.00 Objective: To ensure that terminal supports CVM condition Always Reference: 2RJ.059.0 - Book 3 Section 6.5 - Supported CVR condition: Always Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, always CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 330
2CJ.070.00 Supported CVR condition: If Cash or Cashback

Test No. 2CJ.070.00 Objective: To ensure that terminal supports CVM condition If Cash or Cashback Reference: 2RJ.059.1 - Book 3 Section 6.5 - Supported CVR condition: If Cash or Cashback Conditions: LT supports Cardholder verification Transaction Type is cash CVM in LT is 'Fail CVM, if Cash or Cashback CDOL1 requests TVR and Transaction Type Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 331
2CJ.071.00 Supported CVR condition: If not Cash or Cashback

Test No. 2CJ.071.00 Objective: To ensure that terminal supports CVM condition If not Cash or Cashback Reference: 2RJ.059.2 - Book 3 Section 6.5 - Supported CVR condition: If not Cash or Cashback Conditions: LT supports Cardholder verification Transaction Type is not Cash or Cashback CVM in LT is 'Fail CVM, if not Cash or Cashback' CDOL1 requests TVR and Transaction Type and Amount Authorised and Amount Other Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 332
2CJ.073.00 Supported CVR condition: If Terminal supports the CVM and CVM is offline PIN
Test No. 2CJ.073.00 Objective: To ensure that terminal supports CVM condition If Terminal supports the CVM when CVM is offline PIN Reference: 2RJ.059.4 - Book 3 Section 6.5 - Supported CVR condition: If Terminal supports the CVM and CVM is offline PIN Conditions: LT supports Cardholder verification Terminal supports Offline PIN CVM in LT is 'Plaintext PIN verification performed by ICC, if Terminal supports the CVM' PIN presented is not good or PIN try Counter is 0 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 333
2CJ.074.00 Supported CVR condition: If Terminal supports the CVM and CVM is online PIN
Test No. 2CJ.074.00 Objective: To ensure that terminal supports CVM condition If Terminal supports the CVM when CVM is online PIN Reference: 2RJ.059.5 - Book 3 Section 6.5 - Supported CVR condition: If Terminal supports the CVM and CVM is online PIN Conditions: Application in LT is selected and transaction is processed with LT LT supports Cardholder verification Terminal supports Online PIN CVM in LT is 'Online PIN verification performed by ICC, if Terminal supports the CVM' PIN entered CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification successful. Encrypted PIN Data is sent in the Authorization Request.
Page 334
2CJ.075.00 Supported CVR condition: If Terminal supports the CVM and CVM is signature
Test No. 2CJ.075.00 Objective: To ensure that terminal supports CVM condition If Terminal supports the CVM when CVM is signature Reference: 2RJ.059.6 - Book 3 Section 6.5 - Supported CVR condition: If Terminal supports the CVM and CVM is signature Conditions: LT supports Cardholder verification Terminal supports signature CVM in LT is 'signature, if Terminal supports the CVM' CDOL1 requests CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results shall be set to 1E 03 00
Page 335
2CJ.077.00 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is less than X
Test No. 2CJ.077.00 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under X value when the transaction amount is less than X Reference: 2RJ.059.8 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under X" (1) (Transaction Amount is Less than X) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is under X' Transaction amount is less than X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 336
2CJ.077.01 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is greater than X
Test No. 2CJ.077.01 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under X value when the transaction amount is Greater than X Reference: 2RJ.059.81 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under X" (2) (Transaction Amount is Greater than X) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is under X' followed by Fail CVM, always' Transaction amount is greater than X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 337
2CJ.077.02 Supported CVR condition: If Transaction is in the application currency and is under X value when the transaction amount is equal to X
Test No. 2CJ.077.02 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under X value when the transaction amount is Equal to X Reference: 2RJ.059.82 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under X" (3) (Transaction Amount is Equal to X) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is under X' followed by 'Fail CVM, always' Transaction amount is equal to X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 338
2CJ.078.00 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is greater than X.
Test No. 2CJ.078.00 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over X value when transaction amount is greater than X. Reference: 2RJ.059.9 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over X" (1) (Transaction amount is greater than X). Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over X' Transaction amount is greater than X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 339
2CJ.078.01 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is less than X.
Test No. 2CJ.078.01 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over X value when transaction amount is less than X. Reference: 2RJ.059.91 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over X" (2) (Transaction Amount is Less than X) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over X' followed by 'Fail CVM, always' Transaction amount is less than X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 340
2CJ.078.02 Supported CVR condition: If Transaction is in the application currency and is over X value when transaction amount is equal to X.
Test No. 2CJ.078.02 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over X value when transaction amount is Equal to X. Reference: 2RJ.059.92 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over X" (3) (Transaction Amount is Equal to X) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over X' followed by 'Fail CVM, always' Transaction amount is equal to X value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 341
2CJ.079.00 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is less than Y.
Test No. 2CJ.079.00 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under Y value when the transaction amount is less than Y. Reference: 2RJ.059.10 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under Y" (1) (Transaction amount is less than Y). Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is under Y' Transaction amount is less than Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 342
2CJ.079.01 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is greater than Y
Test No. 2CJ.079.01 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under Y value when the transaction amount is Greater than Y. Reference: 2RJ.059.12 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under Y" (2) (Transaction amount is greater than Y) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM if Transaction is under Y' followed by 'Fail CVM, always' Transaction amount is greater than Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 343
2CJ.079.02 Supported CVR condition: If Transaction is in the application currency and is under Y value when the transaction amount is equal to Y.
Test No. 2CJ.079.02 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is under Y value when the transaction amount is Equal to Y. Reference: 2RJ.059.13 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is under Y" (3) (Transaction amount is equal to Y) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is under Y' followed by 'Fail CVM, always' Transaction amount is equal to Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 344
2CJ.080.00 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is greater than Y.
Test No. 2CJ.080.00 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over Y value when the transaction amount is greater than Y. Reference: 2RJ.059.11 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over Y" (1) (Transaction amount is Greater than Y). Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over Y' Transaction amount is greater than Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 345
2CJ.080.01 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is equal to Y.
Test No. 2CJ.080.01 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over Y value when the transaction amount is equal to Y. Reference: 2RJ.059.14 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over Y" (2) (Transaction amount is Equal to Y) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over Y' followed by 'Fail CVM always' Transaction amount is equal to Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 346
2CJ.080.02 Supported CVR condition: If Transaction is in the application currency and is over Y value when the transaction amount is less than Y.
Test No. 2CJ.080.02 Objective: To ensure that terminal supports CVM condition If Transaction is in the application currency and is over Y value when the transaction amount is less than Y. Reference: 2RJ.059.15 - Book 3 Section 6.5 - Supported CVR condition: "If Transaction is in the application currency and is over Y" (3) (Transaction amount is Less than Y) Conditions: LT supports Cardholder verification CVM in LT is 'Fail CVM, if Transaction is over Y' followed by 'Fail CVM always' Transaction amount is less than Y value Transaction Currency Code equals to Application Currency Code CDOL1 request TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 347
2CJ.081.01 Random Transaction Selection: Transaction Amount Less than the Threshold Value for Biased Random Selection
Test No. 2CJ.081.01 Objective: To ensure that terminal performs Random Transaction Selection checking when the transaction amount is less than the Threshold Value for Biased Random Selection Reference: 2RJ.093.1 - Book 3 Section 6.6.2 - Transaction Amount < Threshold Value and Random Number Target Percentage Conditions: Terminal supports Random Transaction Selection LT supports Terminal Risk Management Transaction Amount is less than the Threshold Value for Biased Random Selection Random Number is less than or equal to Target Percentage to be Used for Random Selection (Test must be repeated until this condition is met) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 5 = 1 ie Transaction selected randomly for online processing
Page 348
2CJ.081.02 Random Transaction Selection: Transaction Amount Less than the Threshold Value for Biased Random Selection
Test No. 2CJ.081.02 Objective: To ensure that terminal performs Random Transaction Selection checking when the transaction amount is less than the Threshold Value for Biased Random Selection Reference: 2RJ.093. 2 - Book 3 Section 6.6.2 - Transaction Amount < Threshold Value and Random Number > Target Percentage Conditions: Terminal supports Random Transaction Selection LT supports Terminal Risk Management Transaction Amount is less than the Threshold Value for Biased Random Selection Random Number is greater than the Target Percentage to be Used for Random Selection (Test must be repeated until this condition is met) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 5 = 0 ie Transaction has not been selected randomly for online processing
Page 349
2CJ.081.03 Random Transaction Selection: Transaction Amount Equal to or Greater than the Threshold Value for Biased Random Selection but Less than the Floor Limit
Test No. 2CJ.081.03 Objective: To ensure that terminal performs Random Transaction Selection checking when the transaction amount is equal to or greater than the Threshold Value for Biased Random Selection but less than the Floor Limit Reference: 2RJ.093. 3 - Book 3 Section 6.6.2 - Threshold Value Transaction Amount < Floor Limit and Random Number Target Percent Conditions: Terminal supports Random Transaction Selection LT supports Terminal Risk Management Transaction Amount is equal to or greater than the Threshold Value for Biased Random Selection but less than the Floor Limit Random Number is less than or equal to Transaction Target Percentage (Test must be repeated until this condition is met) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 5 = 1 ie Transaction selected randomly for online processing
Page 350
2CJ.081.04 Random Transaction Selection: Transaction Amount Equal to or Greater than the Threshold Value for Biased Random Selection but Less than the Floor Limit
Test No. 2CJ.081.04 Objective: To ensure that terminal performs Random Transaction Selection checking when the transaction amount is equal to or greater than the Threshold Value for Biased Random Selection but less than the Floor Limit Reference: 2RJ.093.4 - Book 3 Section 6.6.2 - Threshold Value Transaction Amount < Floor Limit and Random Number > Target Percent Conditions: Terminal supports Random Transaction Selection LT supports Terminal Risk Management Transaction Amount is equal to or greater than the Threshold Value for Biased Random Selection but less than the Floor Limit Random Number is greater than the Transaction Target Percentage (Test must be repeated until this condition is met) CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 5 = 0 ie Transaction has not been selected randomly for online processing
Page 351
2CJ.082.01 CVM List is not present in the ICC

Test No. 2CJ.082.01 Objective: To ensure that terminal does not set the Cardholder verification was performed bit in the TSI to 1b, if CVM List is not present in the ICC Reference: 2RJ.060.0 - Book 3 Section 6.5 - CVM List is not present in the ICC Conditions: LT supports Cardholder verification CVM is not present in the LT CDOL1 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1, bit 7 = 0 ie Cardholder verification was not performed
2CJ.082.02 CVM List is present in the ICC

Test No. 2CJ.082.02 Objective: To ensure that if the CVM List is present in the ICC, the terminal processes each rule in the order in which it appears in the CVM List, until the cardholder verification is completed. Reference: 2RJ.060.1 - Book 3 Section 6.5 - CVM List is present in the ICC Conditions: LT supports Cardholder verification At least two CVM List are tested with several entries CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 shall be set in accordance with CVM List and results of processing
Page 352
2CJ.083.00 Second byte of a Cardholder Verification Rule is not satisfied

Test No. 2CJ.083.00 Objective: To ensure that if the conditions expressed in the second byte of a Cardholder Verification Rule are not satisfied, the terminal bypasses the rules and proceeded to the next rule. Reference: 2RJ.061.0 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification CVM List is 'No CVM required, if transaction is under X' followed by 'Fail CVM, always' X is such as Transaction amount is over X CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 353
2CJ.083.01 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Plaintext PIN
Test No. 2CJ.083.01 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is offline PIN and the terminal does not support offline Plaintext PIN Reference: 2RJ.061.3 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Offline Plaintext PIN CVM in LT is 'Plaintext PIN verification performed by ICC if Terminal supports the CVM' ('01 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed (00 00 01')
Page 354
2CJ.083.02 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Enciphered PIN
Test No. 2CJ.083.02 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is offline PIN and the terminal does not support offline Enciphered PIN Reference: 2RJ.061.4 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Offline Enciphered PIN CVM in LT is 'Offline Enciphered PIN verification performed by ICC if Terminal supports the CVM' ('04 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 355
2CJ.083.03 Non Supported CVR condition: If Terminal supports the CVM and CVM is online Enciphered PIN
Test No. 2CJ.083.03 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is online PIN and the terminal does not support online Enciphered PIN Reference: 2RJ.061.5 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Online Enciphered PIN CVM in LT is 'Online Enciphered PIN verification performed by ICC if Terminal supports the CVM' ('02 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 356
2CJ.083.04 Non Supported CVR condition: If Terminal supports the CVM and CVM is Signature
Test No. 2CJ.083.04 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is Signature and the terminal does not support Signature Reference: 2RJ.061.6 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Signature CVM in LT is 'Signature if Terminal supports the CVM' ('1E 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 357
2CJ.083.05 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Plaintext PIN and Signature
Test No. 2CJ.083.05 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is offline Plaintext PIN and Signature and the terminal does not support offline Plaintext PIN or Signature Reference: 2RJ.061.7 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Offline Plaintext PIN or Signature CVM in LT is 'Offline Plaintext PIN verification performed by ICC and Signature if Terminal supports the CVM' ('03 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 358
2CJ.083.06 Non Supported CVR condition: If Terminal supports the CVM and CVM is offline Enciphered PIN and Signature
Test No. 2CJ.083.06 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is offline Enciphered PIN and Signature and the terminal does not support offline Enciphered PIN or Signature Reference: 2RJ.061.8 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support Offline Enciphered PIN or Signature CVM in LT is 'Offline Enciphered PIN verification performed by ICC and Signature if Terminal supports the CVM' ('05 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 359
2CJ.083.07 No Supported CVR condition: If Terminal supports the CVM and CVM is No CVM Required
Test No. 2CJ.083.07 Objective: To ensure that terminal processes the next CVM in the list when the CVM condition If Terminal supports the CVM when CVM is 'No CVM Required' and the terminal does not support 'No CVM Required' Reference: 2RJ.061.9 - Book 3 Section 6.5 - Second byte of a Cardholder Verification Rule is not satisfied Conditions: LT supports Cardholder verification Terminal does not support 'No CVM Required' CVM in LT is 'No CVM Required if Terminal supports the CVM' ('1F 03') followed by 'Fail CVM, always' ('00 00') CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 360
2CJ.084.00 ICC Data required by the CVM Condition Code is missing

Test No. 2CJ.084.00 Objective: To ensure that if the ICC data required by the condition expressed in the second byte of a Cardholder Verification Rule is not present, the terminal bypasses the rules and proceeded to the next rule. Reference: 2RJ.061.1 - Book 3 Section 6.5 - ICC Data required by the CVM Condition Code is missing Conditions: LT supports Cardholder verification CVM List is Fail CVM if transaction is in the application currency and is under X' followed by 'Fail CVM, always' Application Currency Code is not present in the LT X is such as Transaction amount is under X CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 361
2CJ.085.00 CVM Condition Code is outside the range of codes understood by the terminal
Test No. 2CJ.085.00 Objective: To ensure that if the condition code expressed in the second byte of a Cardholder Verification Rule is outside the range of codes understood by the terminal, the terminal bypasses the rules and proceeded to the next rule. Reference: 2RJ.061.2 - Book 3 Section 6.5 - CVM Condition Code is outside the range of codes understood by the terminal Conditions: LT supports Cardholder verification CVM List is Fail CVM , if RFU' following by 'Fail CVM, always' CDOL1 requests TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 362
2CJ.086.00 Cardholder Verification is not successful

Test No. 2CJ.086.00 Objective: To ensure that the terminal sets to 1b the Cardholder verification was not successful bit if the list of CVM is exhausted and Cardholder Verification has not been successful Reference: 2RJ.062.0 - Book 3 Section 6.5 - Cardholder Verification is not successful Conditions: LT supports Cardholder verification CVM List is 'Plaintext PIN verified by ICC if terminal supports the CVM' followed by 'Fail CVM , if transaction is under X' X is such as transaction Amount is over X PIN is not supported or PIN presented is not good CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed
Page 363
2CJ.087.00 Second byte of Cardholder Verification Rule satisfied and CVM Code is Fail CVM
Test No. 2CJ.087.00 Objective: To ensure that the terminal performs the CVM if the condition code is satisfied and CVM code is fail CVM Reference: 2RJ.063.0 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Fail CVM Conditions: LT supports Cardholder verification CVM List is 'Fail CVM' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 364
2CJ.088.00 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC (Plain text PIN verified by ICC supported)
Test No. 2CJ.088.00 Objective: To ensure that if terminal supports Plaintext PIN verified by ICC, the terminal performs the CVM if the condition code is satisfied and CVM code is Plaintext PIN verified by ICC Reference: 2RJ.063.1 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Plaintext PIN verified by ICC (Plain text PIN verified by ICC supported) Conditions: LT supports Cardholder verification CVM List is 'Plaintext PIN verified by ICC' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports Plaintext PIN verified by ICC Supported PIN presented is not good CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed Terminal shall ask the cardholder to present his PIN TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 365
2CJ.088.01 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC (Plain text PIN verified by ICC not supported)
Test No. 2CJ.088.01 Objective: To ensure that if the terminal does not support Plaintext PIN verified by ICC, the terminal performs the CVM if the condition code is satisfied and CVM code is Plaintext PIN verified by ICC Reference: 2RJ.063.11 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Plaintext PIN verified by ICC (Plain text PIN verified by ICC not supported) Conditions: LT supports Cardholder verification CVM List is 'Plaintext PIN verified by ICC' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support Plaintext PIN verified by ICC CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = '1' i.e. Cardholder verification failed TVR byte 3, bit 5 = 1 i.e. PIN entry required and PIN pad not present TSI byte 1, bit 7 = '1' i.e. Cardholder verification performed
Page 366
2CJ.089.00 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online supported)
Test No. 2CJ.089.00 Objective: To ensure that if terminal supports Enciphered PIN Online, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN Online Reference: 2RJ.063.2 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online supported) Conditions: LT supports Cardholder verification Terminal supports Online verification CVM List is 'Enciphered PIN online' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports Enciphered PIN online PIN is entered CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification success Terminal shall ask the cardholder to present his PIN Encrypted PIN Data is sent in the Authorization Request. TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 367
2CJ.089.01 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online not supported)
Test No. 2CJ.089.01 Objective: To ensure that if the terminal does not support Enciphered PIN Online, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN Online Reference: 2RJ.063.21 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Enciphered PIN Online (Enciphered PIN Online not supported) Conditions: LT supports Cardholder verification Terminal supports Online verification CVM List is 'Enciphered PIN online' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support Enciphered PIN online CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 368
2CJ.090.00 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC and signature (Plain text PIN verified by ICC and signature supported)
Test No. 2CJ.090.00 Objective: To ensure that if terminal supports Plaintext PIN verified by ICC and signature, the terminal performs the CVM if the condition code is satisfied and CVM code is Plaintext PIN verified by ICC and signature Reference: 2RJ.063.3 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Plaintext PIN verified by ICC and signature (Plain text PIN verified by ICC and signature supported) Conditions: LT supports Cardholder verification CVM List is 'Plaintext PIN verified by ICC and signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports Plaintext PIN verified by ICC Supported PIN presented is not good CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed Terminal shall ask the cardholder to present his PIN TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 369
2CJ.090.01 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC and signature (Plain text PIN verified by ICC and signature not supported)
Test No. 2CJ.090.01 Objective: To ensure that if the terminal does not support Plaintext PIN verified by ICC and signature, the terminal performs the CVM if the condition code is satisfied and CVM code is Plaintext PIN verified by ICC and signature Reference: 2RJ.063.31 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Plaintext PIN verified by ICC and signature (Plain text PIN verified by ICC and signature not supported) Conditions: LT supports Cardholder verification CVM List is 'Plaintext PIN verified by ICC and signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support Plaintext PIN verified by ICC CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 370
2CJ.091.00 Second byte of CVR satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC supported)
Test No. 2CJ.091.00 Objective: To ensure that if terminal supports Enciphered PIN verified by ICC, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN verified by ICC Reference: 2RJ.063.4 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC supported) Conditions: LT supports Cardholder verification CVM List is 'Enciphered PIN verified by ICC' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports Enciphered PIN verified by ICC Supported PIN presented is not good CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed Terminal shall ask the cardholder to present his PIN TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 371
2CJ.091.01 Second byte of CVR satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC not supported)
Test No. 2CJ.091.01 Objective: To ensure that if the terminal does not support Enciphered PIN verified by ICC, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN verified by ICC Reference: 2RJ.063.41 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is Enciphered PIN verified by ICC (Enciphered PIN verified by ICC not supported) Conditions: LT supports Cardholder verification CVM List is 'Enciphered PIN verified by ICC' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support Enciphered PIN verified by ICC CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 372
2CJ.092.00 Second byte of CVR satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature supported)
Test No. 2CJ.092.00 Objective: To ensure that if terminal supports Enciphered PIN verified by ICC and signature, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN verified by ICC and signature Reference: 2RJ.063.5 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature supported) Conditions: LT supports Cardholder verification CVM List is 'Enciphered PIN verified by ICC and signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports Enciphered PIN verified by ICC Supported PIN presented is not good CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed Terminal shall ask the cardholder to present his PIN TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 373
2CJ.092.01 Second byte of CVR satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature not supported)
Test No. 2CJ.092.01 Objective: To ensure that if the terminal does not support Enciphered PIN verified by ICC and signature, the terminal performs the CVM if the condition code is satisfied and CVM code is Enciphered PIN verified by ICC and signature Reference: 2RJ.063.51 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code Enciphered PIN verified by ICC and signature (Enciphered PIN verified by ICC and signature not supported) Conditions: LT supports Cardholder verification CVM List is 'Enciphered PIN verified by ICC and signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support Enciphered PIN verified by ICC and signature CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 374
2CJ.093.00 Second byte of CVR satisfied and CVM Code is signature (signature supported)
Test No. 2CJ.093.00 Objective: To ensure that if terminal supports signature, the terminal performs the CVM if the condition code is satisfied and CVM code is signature Reference: 2RJ.063.6 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is signature (signature supported) Conditions: LT supports Cardholder verification CVM List is 'signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports signature CDOL1 requests TVR and TSI Transaction is processed so the outcome is an Approval Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall print a ticket with signature line TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 375
2CJ.093.01 Second byte of CVR satisfied and CVM Code is signature (signature not supported)
Test No. 2CJ.093.01 Objective: To ensure that if the terminal does not support signature, the terminal performs the CVM if the condition code is satisfied and CVM code is signature Reference: 2RJ.063.61 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is signature (signature not supported) Conditions: LT supports Cardholder verification CVM List is 'signature' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support signature CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = '1' ie Cardholder verification performed
Page 376
2CJ.094.00 Second byte of CVR satisfied and CVM Code is no CVM required (No CVM required is supported)
Test No. 2CJ.094.00 Objective: To ensure that if terminal supports No CVM required, the terminal considers that the CVM is successful if the condition code is satisfied and CVM code is 'No CVM required' Reference: 2RJ.063.7 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is No CVM required (No CVM required is supported) Conditions: LT supports Cardholder verification CVM List is 'No CVM required' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal supports 'No CVM required' CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification succeeded TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 377
2CJ.094.01 Second byte of CVR satisfied and CVM Code is No CVM required (No CVM required is not supported)
Test No. 2CJ.094.01 Objective: To ensure that if the terminal does not support 'No CVM required', the terminal considers that the CVM is successful if the condition code is satisfied and CVM code is 'No CVM required' Reference: 2RJ.063.71 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code is No CVM required (No CVM required is not supported) Conditions: LT supports Cardholder verification CVM List is 'No CVM required' with a satisfied condition i.e. * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) Terminal does not support 'No CVM required' CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 378
2CJ.095.00 Second byte of CVR satisfied and CVM Code not understood by the terminal
Test No. 2CJ.095.00 Objective: To ensure that the terminal sets the Unrecognized CVM bit in the TVR to 1b, if the condition code is satisfied and CVM code is not understood by the terminal (RFU) Reference: 2RJ.064.0 - Book 3 Section 6.5 - Second byte of Cardholder Verification Rule satisfied and CVM Code not understood by the terminal Conditions: LT supports Cardholder verification CVM List is 'RFU' with a satisfied condition ie * always or * cash or cashback (and Transaction is cash) or * transaction is under X (and Amount is under X) or * transaction is over Y (and Amount is over Y) CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 7 = 1 ie Unrecognized CVM TSI byte 1, bit 7 = '1' ie Cardholder Verification was performed
Page 379
2CJ.096.00 CVM processing succeeds

Test No. 2CJ.096.00 Objective: To ensure that the terminal does not set the Cardholder verification was not successful bit bit in the TVR to 1b, if the CVM processing succeeds Reference: 2RJ.065.0 - Book 3 Section 6.5 - CVM processing succeeds Conditions: LT supports Cardholder verification CDOL1 requests TSI and TVR CVM List such as at least one condition is met and CVM is performed OK (test can be made for several CVM: plaintext PIN verified by ICC, online PIN, signature...) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 380
2CJ.097.00 CVM processing fails and CVR indicates to proceed with next rule
Test No. 2CJ.097.00 Objective: To ensure that the terminal processes next CVR in the CVM List, if the current one is not successful and the Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful bit is set to 1b Reference: 2RJ.066.0 - Book 3 Section 6.5 - CVM processing fails and Cardholder Verification Rules indicates to proceed with next rule Conditions: LT supports Cardholder verification CDOL1 requests TSI and TVR CVM List such as it contains 2 CVRs and the first one has Apply succeeding Cardholder Verification Rule, if this CVM is unsuccessful bit is set to 1b and is not successful whereas the second one is performed OK ( test can be made for several CVM: plaintext PIN verified by ICC, online PIN, signature...) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 381
2CJ.098.00 CVM processing fails and no more CVR in the CVM List
Test No. 2CJ.098.00 Objective: To ensure that the terminal fails the Cardholder verification and sets the Cardholder verification was not successful in the TVR to 1b, if a CVM processing fails , and the Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful bit is set to 1b, and there are no more Cardholder Verification Rules in the CVM List Reference: 2RJ.067.0 - Book 3 Section 6.5 - CVM processing fails and no more Cardholder Verification Rules in the CVM List Conditions: LT supports Cardholder verification CVM List such as it contains only one CVR with condition OK but CVM is not performed OK and this CVM has Apply succeeding Cardholder Verification Rule, if this CVM is unsuccessful bit is set to 1b CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful
Page 382
2CJ.099.00 CVM processing fails and CVR indicates to not proceed with next rule
Test No. 2CJ.099.00 Objective: To ensure that the terminal fails the Cardholder verification and sets the Cardholder verification was not successful in the TVR to 1b, if a CVM processing fails , and the Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful bit is not set to 1b. Reference: 2RJ.068.0 - Book 3 Section 6.5 - CVM processing fails and Cardholder Verification Rules indicates to not proceed with next rule Conditions: LT supports Cardholder verification CVM List such it contains one or several CVR and first CVR with condition OK but CVM is not performed OK and this CVM has Apply succeeding Cardholder Verification Rule if this CVM is unsuccessful bit is not set to 1b CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful
Page 383
2CJ.100.00 Cardholder Verification is completed

Test No. 2CJ.100.00 Objective: To ensure that the terminal sets the Cardholder verification was performed bit in the TSI to 1b, if the Cardholder verification process is performed (successful or not) Reference: 2RJ.069.0 - Book 3 Section 6.5 - Cardholder Verification is completed Conditions: LT supports Cardholder verification CVM List present (test is made for 2 cases CVM such as Cardholder verification is OK and CVM such as Cardholder verification fails) CDOL1 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 384
2CJ.102.00 Offline PIN verification returns 63 Cx

Test No. 2CJ.102.00 Objective: To ensure that the terminal displays a specific message and prompts for a second PIN entry if the VERIFY command returns 63 Cx and x is greater than 0 Reference: 2RJ.070.1 - Book 3 Section 6.5 - Offline PIN verification returns 63 Cx Conditions: LT supports Cardholder verification Terminal supports Offline PIN verification CVM List is 'PIN verified by ICC, always' LT returns 63C2 to VERIFY command Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display a specific message and shall prompt for PIN entry
Page 385
2CJ.103.00 Offline PIN is the selected CVM and Terminal does not support offline PIN
Test No. 2CJ.103.00 Objective: To ensure that the terminal sets the PIN entry required and PIN pad not present or not working bit in the TVR to 1b, if an offline PIN is the selected CVM and the terminal does not support either offline plaintext PIN verification or offline enciphered PIN verification. Reference: 2RJ.071.0 - Book 3 Section 6.5.1 - Offline PIN is the selected CVM and Terminal does not support offline PIN Conditions: LT supports Cardholder verification Terminal does not support Offline PIN verification CVM List is 'PIN verified by ICC, always' CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present
Page 386
2CJ.104.00 Offline PIN is the selected CVM, Terminal supports offline PIN, and the PIN pad is malfunctioning
Test No. 2CJ.104.00 Objective: To ensure that the terminal sets the PIN entry required and PIN pad not present or not working bit in the TVR to 1b, if an offline PIN is the selected CVM and the terminal PIN Pad is malfunctioning. Reference: 2RJ.072.0 - Book 3 Section 6.5.1 - Offline PIN is the selected CVM, Terminal supports offline PIN, and the PIN pad is malfunctioning Conditions: LT supports Cardholder verification Terminal PIN Pad is malfunctioning CVM List is 'PIN verified by ICC, always' PIN pad to be non functional pad CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present
Page 387
2CJ.106.00 Offline PIN is the selected CVM and PIN is blocked

Test No. 2CJ.106.00 Objective: To ensure that the terminal sets the PIN Try Limit exceeded bit in the TVR to 1b, if an offline PIN is the selected CVM and the PIN is blocked upon initial use of the VERIFY command (i.e. the status code is either 6983 or 6984). Reference: 2RJ.074.0 - Book 3 Section 6.5.1 - Offline PIN is the selected CVM and PIN is blocked Conditions: LT supports Cardholder verification Terminal supports Offline PIN verification CVM List is 'PIN verified by ICC, always' LT returns 6983 or 6984 to VERIFY command CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 6 = 1 ie PIN Try Limit exceeded
Page 388
2CJ.107.00 Offline PIN is the selected CVM and the number of remaining PIN trials is zero
Test No. 2CJ.107.00 Objective: To ensure that the terminal sets the PIN Try Limit exceeded bit in the TVR to 1b, if an offline PIN is the selected CVM and the number of remaining PIN trials is reduced to zero upon initial use of the VERIFY command (i.e. the status code is 63C0), Reference: 2RJ.075.0 - Book 3 Section 6.5.1 -Offline PIN is the selected CVM and the number of remaining PIN trials is zero Conditions: LT supports Cardholder verification Terminal supports Offline PIN verification CVM List is 'PIN verified by ICC, always' LT returns 63C0 to VERIFY command CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 6 = 1 ie PIN Try Limit exceeded
Page 389
2CJ.108.00 Offline PIN is the selected CVM and the offline PIN processing is successful
Test No. 2CJ.108.00 Objective: To ensure that the terminal consider the CVM as successful, if an offline PIN is the selected CVM and VERIFY command returns 90 00 Reference: 2RJ.076.0 - Book 3 Section 6.5.1 - Offline PIN is the selected CVM and the offline PIN processing is successful Conditions: LT supports Cardholder verification Terminal supports Offline PIN verification CVM List is 'PIN verified by ICC, always' LT returns 90 00 to VERIFY command CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 390
2CJ.109.00 Online PIN is the selected CVM and Terminal does not support online PIN
Test No. 2CJ.109.00 Objective: To ensure that the terminal sets the PIN entry required and PIN pad not present or not working bit in the TVR to 1b, if enciphered PIN verified online is the selected CVM and the terminal does not support enciphered PIN verified online. Reference: 2RJ.077.0 - Book 3 Section 6.5.2 - Online PIN is the selected CVM and Terminal does not support online PIN Conditions: LT supports Cardholder verification Terminal does not support enciphered PIN verified online CVM List is 'Enciphered PIN verified online, always' CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present
Page 391
2CJ.110.00 Online PIN is the selected CVM, Terminal supports online PIN, and the PIN pad is malfunctioning
Test No. 2CJ.110.00 Objective: To ensure that the terminal sets the PIN entry required and PIN pad not present or not working bit in the TVR to 1b, if enciphered PIN verified online is the selected CVM and the terminal PIN Pad is malfunctioning. Reference: 2RJ.078.0 - Book 3 Section 6.5.2 - Online PIN is the selected CVM, Terminal supports online PIN, and the PIN pad is malfunctioning Conditions: LT supports Cardholder verification Terminal PIN Pad is malfunctioning CVM List is 'Enciphered PIN verified online' always' CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was not successful TVR byte 3, bit 5 = 1 ie PIN entry required and PIN pad not present
Page 392
2CJ.112.00 Online PIN is the selected CVM and the online PIN processing is successful
Test No. 2CJ.112.00 Objective: To ensure that the terminal consider the CVM as successful, if enciphered PIN verified online is the selected CVM and Issuer answered that PIN presented is good Reference: 2RJ.080.0 - Book 3 Section 6.5.2 - Online PIN is the selected CVM and the online PIN processing is successful Conditions: LT supports Cardholder verification Terminal supports enciphered PIN verified online CVM List is 'Enciphered PIN verified online, always' Issuer returns an acceptance CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 393
2CJ.113.00 Signature (paper) is a required CVM and Terminal supports the signature process
Test No. 2CJ.113.00 Objective: To ensure that the terminal consider the CVM as successful, if signature is the selected CVM and terminal supports the signature process Reference: 2RJ.081.0 - Book 3 Section 6.5.3 - Signature (paper) is a required CVM and Terminal supports the signature process Conditions: LT supports Cardholder verification Terminal supports signature CVM List is 'signature, always' CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 394
2CJ.114.00 Combination CVM: success

Test No. 2CJ.114.00 Objective: To ensure that if a CVM requires multiple verification methods (for example, offline PIN plus signature), the terminal considers the CVM as successful, if all methods in the CVM are successful Reference: 2RJ.082.0 - Book 3 Section 6.5.4 - Combination CVM: success Conditions: LT supports Cardholder verification Terminal supports signature Terminal supports plaintext PIN PIN entered is good CVM List is 'Plaintext PIN verified by ICC plus signature, always' CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 395
2CJ.115.00 Combination CVM: failure

Test No. 2CJ.115.00 Objective: To ensure that if a CVM requires multiple verification methods (for example, offline PIN plus signature), the terminal considers the CVM as failed, if one of the methods in the CVM fails Reference: 2RJ.082.1 - Book 3 Section 6.5.4 - Combination CVM: failure Conditions: LT supports Cardholder verification Terminal supports plaintext PIN One test is made with PIN entered is not good and Terminal supports signature, a second one with PIN entered is good and Terminal does not support signature CVM List is 'Plaintext PIN verified by ICC plus signature, always' CDOL1 requests TVR and TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification failed TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 396
2CJ.116.00 Terminal Risk Management is supported in AIP

Test No. 2CJ.116.00 Objective: To ensure that if the card supports Terminal Risk Management, the terminal performs Risk Management at any time after Read Application Data and prior to the issuing of the first GENERATE AC command Reference: 2RJ.083.0 - Book 3 Section 6.6 - Terminal Risk Management is supported in AIP Conditions: LT supports Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI, TVR, Terminal Floor Limit and Amount Authorized Numeric Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed TVR byte 2, bit 4 = 0 ie New Card TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 397
2CJ.118.00 Terminal Risk Management is not supported in AIP

Test No. 2CJ.118.00 Objective: To ensure that if the card does not support Terminal Risk Management, the terminal does not perform Floor Limit checking, Random transaction selection and velocity checking Reference: 2RJ.085.0 - Book 3 Section 6.6 - Terminal Risk Management is not supported in AIP Conditions: LT does not support Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI and TVR and Terminal Floor Limit and Amount Authorized Numeric Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 0 ie Transaction does not exceed floor limit TVR byte 4, bit 7 = 0 ie Lower Consecutive Offline Limit is not exceeded TVR byte 4, bit 6 = 0 ie Upper Consecutive Offline Limit is not exceeded TSI byte 1, bit 4 = 0 ie Terminal Risk Management was not performed
Page 398
2CJ.119.00 Transaction log entry with the same PAN is available and Terminal Floor Limit is exceeded
Test No. 2CJ.119.00 Objective: To ensure that the terminal sets the Transaction exceeds floor limit bit in the TVR to 1b, if a transaction log entries with the same Application PAN, is available and if the sum of the Amount, Authorized to the Amount stored in the most recent log entry for that PAN is greater than or equal to the Terminal Floor Limit Reference: 2RJ.086.0 - Book 3 Section 6.6.1 - Transaction log entry with the same PAN is available and Terminal Floor Limit is exceeded Conditions: LT supports Terminal Risk Management Transaction log is available if supported by the terminal with the same PAN as the LT PAN (another transaction has been made with same PAN before with Amount less than Terminal floor Limit) sum of Transaction Amount, Authorized and Amount stored in the log is equal to or greater than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and sum of Transaction Amount, Authorized and Amount of previous transaction with same PAN is equal to or greater than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 399
2CJ.120.00 Transaction log entry with the same PAN is available and Terminal Floor Limit is not exceeded (implied)
Test No. 2CJ.120.00 Objective: To ensure that the terminal does not set the Transaction exceeds floor limit bit in the TVR to 1b, if a transaction log entries with the same Application PAN, is available and if the sum of the Amount, Authorized to the Amount stored in the most recent log entry for that PAN is less than the Terminal Floor Limit Reference: 2RJ.086.1 - Book 3 Section 6.6.1 - Transaction log entry with the same PAN is available and Terminal Floor Limit is not exceeded (implied) Conditions: LT supports Terminal Risk Management Transaction log is available if supported by the terminal with the same PAN as the LT PAN (another transaction has been made with same PAN before with Amount less than Terminal floor Limit) Sum of Transaction Amount, Authorized and Amount stored in the log is less than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 0 ie Transaction does not exceed floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and sum of Transaction Amount, Authorized and Amount of previous transaction with same PAN is less than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 400
2CJ.123.00 Transaction log is not available and Terminal Floor Limit is exceeded
Test No. 2CJ.123.00 Objective: To ensure that the terminal sets the Transaction exceeds floor limit bit in the TVR to 1b, if no transaction log is available and if the Amount, Authorized is greater than or equal to the Terminal Floor Limit Reference: 2RJ.087.0 - Book 3 Section 6.6.1 - Transaction log is not available and Terminal Floor Limit is exceeded Conditions: LT supports Terminal Risk Management Transaction log is not available Transaction Amount, Authorized is equal to or greater than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and Transaction Amount, Authorized is equal to or greater than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 401
2CJ.124.00 Transaction log is not available and Terminal Floor Limit is not exceeded (implied)
Test No. 2CJ.124.00 Objective: To ensure that the terminal does not set the Transaction exceeds floor limit bit in the TVR to 1b, if no transaction log is available and if the Amount, Authorized is less than the Terminal Floor Limit Reference: 2RJ.087.1 - Book 3 Section 6.6.1 - Transaction log is not available and Terminal Floor Limit is not exceeded (implied) Conditions: LT supports Terminal Risk Management Transaction log is not available Transaction Amount, Authorized is less than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 0 ie Transaction does not exceed floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and Transaction Amount, Authorized is less than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 402
2CJ.127.00 Transaction log entry with the same PAN is not available and Terminal Floor Limit is exceeded
Test No. 2CJ.127.00 Objective: To ensure that the terminal sets the Transaction exceeds floor limit bit in the TVR to 1b, if no transaction log with the same PAN is available and if the Amount, Authorized is greater than or equal to the Terminal Floor Limit Reference: 2RJ.088.0 - Book 3 Section 6.6.1 - Transaction log entry with the same PAN is not available and Terminal Floor Limit is exceeded Conditions: LT supports Terminal Risk Management Transaction log is not available for same PAN (another transaction as been made with another PAN before with Amount less than Terminal floor Limit) Transaction Amount, Authorized is equal to or greater than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and Transaction Amount, Authorized is equal to or greater than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 403
2CJ.128.00 Transaction log entry with the same PAN is not available and Terminal Floor Limit is not exceeded (implied)
Test No. 2CJ.128.00 Objective: To ensure that the terminal does not set the Transaction exceeds floor limit bit in the TVR to 1b, if no transaction log with the same PAN is available and if the Amount, Authorized is less than the Terminal Floor Limit Reference: 2RJ.088.1 - Book 3 Section 6.6.1 - Transaction log entry with the same PAN is not available and Terminal Floor Limit is not exceeded (implied) Conditions: LT supports Terminal Risk Management Transaction log is not available for same PAN (another transaction has been made with another PAN before with Amount less than Terminal floor Limit) Transaction Amount, Authorized is less than Terminal floor Limit (Amount Authorized can include a cash back amount) CDOL1 requests TVR and TSI and Terminal Floor Limit and Amount Authorized Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 0 ie Transaction does not exceed floor limit Amount Authorized returned in First GENERATE AC is the same as the amount entered and Transaction Amount, Authorized is less than Terminal floor Limit TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 404
2CJ.137.00 Both the Lower and the Upper Consecutive Offline Limit are present in the ICC
Test No. 2CJ.137.00 Objective: To ensure that if Lower and Upper Consecutive Offline Limits are present in the card, the terminal performs the velocity checking Reference: 2RJ.095.0 - Book 3 Section 6.6.3 - Both the Lower and the Upper Consecutive Offline Limit are present in the ICC Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL 1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TVR byte 2, bit 4 = 0 ie New Card TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 405
2CJ.138.00 Either the Lower or the Upper Consecutive Offline Limit is not present in the ICC
Test No. 2CJ.138.00 Objective: To ensure that if either Lower or Upper Consecutive Offline Limits is absent in the card, the terminal does not perform the velocity checking Reference: 2RJ.096.0 - Book 3 Section 6.6.3 - Either the Lower or the Upper Consecutive Offline Limit is not present in the ICC Conditions: LT supports Terminal Risk Management either Lower or Upper Consecutive Offline Limits is absent in the LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 0 ie Lower Consecutive Offline Limit not exceeded TVR byte 4, bit 6 = 0 ie Upper Consecutive Offline Limit not exceeded The terminal shall not issue the GET DATA command for the ATC or the LOATC
Page 406
2CJ.139.00 GET DATA on both the ATC and the Last Online ATC Register
Test No. 2CJ.139.00 Objective: To ensure that if terminal performs the velocity checking, it reads the ATC and Last online ATC using GET DATA command Reference: 2RJ.097.0 - Book 3 Section 6.6.3 - GET DATA on both the ATC and the Last Online ATC Register Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT shall receive 2 GET DATAs command for ATC and Last Online ATC
Page 407
2CJ.140.00 The ATC Register is not present in the ICC

Test No. 2CJ.140.00 Objective: To ensure that if the ATC is not returned by the card in response to the GET DATA command, the terminal sets both the Lower consecutive offline limit exceeded and the Upper consecutive offline limit exceeded bits in the TVR to 1b and does not set the New Card bit in the TVR to 1b Reference: 2RJ.098.0 - Book 3 Section 6.6.3 - Either the ATC or the Last Online ATC Register is not present in the ICC Conditions: LT supports Terminal Risk Management (AIP) Terminal shall support Risk management Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA If returned, Last Online ATC is 0 CDOL1 Requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TVR byte 2, bit 4 = 0 ie not a new card TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 408
2CJ.140.01 The Last Online ATC Register is not present in the ICC
Test No. 2CJ.140.01 Objective: To ensure that if the Last Online ATC is not returned by the card in response to the GET DATA command, the terminal sets both the Lower consecutive offline limit exceeded and the Upper consecutive offline limit exceeded bits in the TVR to 1b and does not set the New Card bit in the TVR to 1b Reference: 2RJ.098.0 - Book 3 Section 6.6.3 - Either the ATC or the Last Online ATC Register is not present in the ICC Conditions: LT supports Terminal Risk Management (AIP) Terminal shall support Risk management Lower and Upper Consecutive Offline Limits are present in the LT Last Online ATC is not returned by GET DATA If returned, Last Online ATC is 0 CDOL1 Requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TVR byte 2, bit 4 = 0 ie not a new card TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 409
2CJ.141.00 (ATC - Last Online ATC Register) > Lower Consecutive Offline Limit
Test No. 2CJ.141.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is greater than the Lower Consecutive Offline Limit, the terminal sets the Lower consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.099.0 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) > Lower Consecutive Offline Limit Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC > Lower Consecutive Offline Limit CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded
Page 410
2CJ.142.00 (ATC - Last Online ATC Register) = Lower Consecutive Offline Limit (implied)
Test No. 2CJ.142.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is equal to the Lower Consecutive Offline Limit, the terminal does not set the Lower consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.099.1 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) = Lower Consecutive Offline Limit (implied) Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC = Lower Consecutive Offline Limit Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 Requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 0 ie Lower Consecutive Offline Limit not exceeded
Page 411
2CJ.143.00 (ATC - Last Online ATC Register) < Lower Consecutive Offline Limit (implied)
Test No. 2CJ.143.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is less than the Lower Consecutive Offline Limit, the terminal does not set the Lower consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.099.2 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) < Lower Consecutive Offline Limit (implied) Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC < Lower Consecutive Offline Limit Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 7 = 0 ie Lower Consecutive Offline Limit not exceeded
Page 412
2CJ.144.00 (ATC - Last Online ATC Register) > Upper Consecutive Offline Limit
Test No. 2CJ.144.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is greater than the Upper Consecutive Offline Limit, the terminal sets the Upper consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.100.0 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) > Upper Consecutive Offline Limit Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC > Upper Consecutive Offline Limit CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded
Page 413
2CJ.145.00 (ATC - Last Online ATC Register) = Upper Consecutive Offline Limit (implied)
Test No. 2CJ.145.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is equal to the Upper Consecutive Offline Limit, the terminal does not set the Upper consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.100.1 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) = Upper Consecutive Offline Limit (implied) Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC = Upper Consecutive Offline Limit Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 6 = 0 ie Upper Consecutive Offline Limit not exceeded
Page 414
2CJ.146.00 (ATC - Last Online ATC Register) < Upper Consecutive Offline Limit (implied)
Test No. 2CJ.146.00 Objective: To ensure that if the difference between the ATC and the Last Online ATC Register is less than the Upper Consecutive Offline Limit, the terminal does not set the Upper consecutive offline limit exceeded bit in the TVR to 1b Reference: 2RJ.100.2 - Book 3 Section 6.6.3 - (ATC - Last Online ATC Register) < Upper Consecutive Offline Limit (implied) Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA ATC - Last Online ATC < Upper Consecutive Offline Limit Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 6 = 0 ie Upper Consecutive Offline Limit not exceeded
Page 415
2CJ.147.00 Last Online ATC Register = 0

Test No. 2CJ.147.00 Objective: To ensure that if the Last Online ATC is equal to 0, the terminal sets the New card bit in the TVR to 1b Reference: 2RJ.101.0 - Book 3 Section 6.6.3 - Last Online ATC Register = 0 Conditions: LT supports Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA Last Online ATC when returned by GET DATA have the value = 0 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 2, bit 4 = 1 ie New Card
Page 416
2CJ.148.00 Terminal Risk Management completion

Test No. 2CJ.148.00 Objective: To ensure that the terminal sets the Terminal Risk Management was performed bit in the TSI to 1b, when the Terminal Risk management is completed Reference: 2RJ.102.0 - Book 3 Section 6.6.3 - Terminal Risk Management completion Conditions: LT supports Terminal Risk Management consists of: Floor Limit Checking Random Transaction Selection Velocity Checking Terminal Supports minimum of one form of Terminal Risk Management Lower and Upper Consecutive Offline Limits are present in the LT ATC and Last Online ATC are returned by GET DATA CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 417
2CJ.149.00 Terminal Action Analysis function execution

Test No. 2CJ.149.00 Objective: To ensure that the terminal performs Action Analysis prior to the issuing of the first GENERATE AC command Reference: 2RJ.103.0 - Book 3 Section 6.7 - Terminal Action Analysis function execution Conditions: IAC and data in the LT are populated so that Terminal decision following Action Analysis is TC, ARQC and AAC (3 cases) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting a cryptogram in accordance with IAC and Data Above
Page 418
Terminal Action Code (TAC)

2CJ.150.00 TAC Denial processing bit set to 1b
Test No. 2CJ.150.00 Objective: To ensure that the terminal issues a GENERATE AC requesting an AAC, if for a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to 1b Reference: 2RJ.115.1 Book 3 Section 6.7 - TVR and Terminal Action Code Denial check requests an AAC. Conditions: Terminal Action Code Denial has one bit set to 1b and the corresponding TVR bit is set to 1b Terminal Action Code Default have all bits set to 0b Issuer Action Codes has all bits set to 0b AIP must be set to execute the function associated with the TAC bit selected by tester and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an AAC in all cases
Page 419
2CJ.151.00 TAC Denial processing bit set to 0b

Test No. 2CJ.151.00 Objective: To ensure that the terminal issues a GENERATE AC requesting a TC, if for a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to 0b Reference: 2RJ.112.0 - Book 3 Section 6.7 - Denial Action Codes processing. The terminal shall process first the denial Action Codes during the terminal action analysis. Conditions: Terminal Action Code Denial has one bit set to 0b and the corresponding TVR bit is set to 1b Terminal Action Codes Online & Default have all bits set to 0b Issuer Actions Codes have all bits set to 0b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an TC in all cases.
Page 420
2CJ.152.00 TAC Online Processing, bit set to 1b

Test No. 2CJ.152.00 Objective: To ensure that the terminal issues a GENERATE AC requesting an ARQC, if the terminal has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the TAC Online is set to 1b Reference: 2RJ.116.1 - Book 3 Section 6.7 - Terminal has online capability, TVR and Terminal Action Code-Online check requests an ARQC Conditions: Terminal has online capabilities Issuer Action Codes have all bits set to 0b Terminal Action Code Online has one bit set to 1b and the corresponding TVR bit is set to 1b Terminal Action Code Denial has all bits set to 0b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an ARQC in all cases
Page 421
2CJ.153.00 TAC Online Processing, bit set to 0b

Test No. 2CJ.153.00 Objective: To ensure that the terminal issues a GENERATE AC requesting a TC, if the terminal has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the TAC Online is set to 0b Reference: 2RJ.116.2 - Book 3 Section 6.7 - Terminal has online capability, TVR and Online Action Codes check does not request an ARQC Conditions: Terminal Action Code Online has one bit set to 0b and the corresponding TVR bit is set to 1b Terminal Action Code Denial has all bits set to 0b Issuer Action Codes have all bits set to 0b Terminal has online capabilities AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting a TC in all cases
Page 422
2CJ.154.00 TAC Default processing bit set to 1b, & terminal unable to go online
Test No. 2CJ.154.00 Objective: To ensure that the terminal issues a second GENERATE AC requesting an AAC, if online connection was requested after first GENERATE AC and terminal is unable to go online and for a bit set to 1b in the TVR, the corresponding bit in the TAC Default is set to 1b Reference: 2RJ.117.1 - Book 3 Section 6.7 - Terminal is unable to go online, TVR and Terminal Action Code-Default check requests an AAC Conditions: Terminal Action Codes Denial have all bits set to 0b LT returns ARQC to first GENERATE AC command Terminal has online capabilities, and is unable to go online Issuer Action Codes have all bits set to 0b Terminal Action Code Default has one bit set to 1b and the corresponding TVR bit is set to 1b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting an AAC in all cases
Page 423
2CJ.155.00 TAC Default processing bit set to 0b, & terminal unable to go online
Test No. 2CJ.155.00 Objective: To ensure that the terminal issues a second GENERATE AC requesting a TC, if online connection was requested after first GENERATE AC and terminal is unable to go online and for each bit set to 1b in the TVR, the corresponding bit in both the IAC Default and TAC-Default is set to 0b Reference: 2RJ.118.0 - Book 3 Section 6.7 - Terminal is unable to go online, TVR and Default Action Codes check requests a TC Conditions: Terminal Action Codes Denial have all bit set to 0b LT returns ARQC to first GENERATE AC command Terminal has online capabilities and unable to go online Issuer Action Codes have all bits set to 0b Terminal Action Code Default has one bit set to 0b and the corresponding TVR bit is set to 1b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting a TC in all cases
Page 424
2CJ.156.00 TAC Default processing bit set to 1b, & terminal has no online capability
Test No. 2CJ.156.00 Objective: To ensure that the terminal skips the check of Online Action Codes and issues a first GENERATE AC requesting an AAC, if terminal has no online capabilities and for a bit set to 1b in the TVR, the corresponding bit in the TAC Default is set to 1b Reference: 2RJ.120.1 - Book 3 Section 6.7 - Terminal has not online capability, TVR and Terminal Action Codes-Default check requests an AAC Conditions: Terminal Action Code Denial has all bit set to 0b Terminal Action Code Online has all bit set to 1b Terminal has no online capabilities Issuer Action Codes have all bits set to 0b Terminal Action Code Default has one bit set to 1b and the corresponding TVR bit is set to 1b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an AAC in all cases
Page 425
2CJ.157.00 TAC Default processing bit set to 0b, & terminal has no online capability
Test No. 2CJ.157.00 Objective: To ensure that the terminal skips the check of Online Action Codes and issues a first GENERATE AC requesting a TC, if terminal has no online capability and for each bit set to 1b in the TVR, the corresponding bit in both the IAC Default and TAC-Default is set to 0b Reference: 2RJ.121.0 - Book 3 Section 6.7 - Terminal has not online capability, TVR and Default Action Codes check requests a TC Conditions: Terminal Action Code Denial has all bit set to 0b Issuer Action Code Denial has all bit set to 0b Terminal Action Code Online has all bit set to 1b Terminal has no online capabilities Issuer Action Code Default has all bits set to 0b Terminal Action Code Default has one bit set to 0b and the corresponding TVR bit is set to 1b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting a TC in all cases
Page 426
Issuer Action Code (IAC)

2CJ.158.00 TVR and Issuer Action Code-Denial check requests an AAC
Test No. 2CJ.158.00 Objective: To ensure that the terminal issues a GENERATE AC requesting an AAC if for a bit is set to 1b in the TVR the corresponding bit in the IAC Denial is set to 1b. Reference: 2RJ.111.0 - Book 3 Section 6.7 - TVR and Issuer Action Code-Denial check requests an AAC Conditions: Issuer Action Code Denial has one bit set to 1b and the corresponding TVR bit is set to 1b Issuer Action Code Default has all bits set to 0b Terminal Action Codes have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by tester and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an AAC in all cases
Page 427
2CJ.159.00 (implied)
Test No. 2CJ.159.00
TVR and IAC-Denial check requests a TC
Objective: To ensure that the terminal issues a GENERATE AC requesting a TC if for a bit is set to 1b in the TVR, the corresponding bit in the IAC Denial is set to 0b. Reference: 2RJ.111.5 - Book 3 Section 6.7 - TVR and IAC-Denial check requests a TC (implied) Conditions: Terminal Action Codes have all bits set to 0b Issuer Actions Code Denial has one bit set to 0b and the corresponding TVR bit is set to 1b Issuer Actions Codes Online & Default have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an TC in all cases
Page 428
2CJ.160.00 Terminal has online capability, TVR and Issuer Action Code-Online check requests an ARQC
Test No. 2CJ.160.00 Objective: To ensure that the terminal issues a GENERATE AC requesting an ARQC, if the terminal has online capabilities and if for a bit set to 1b in the TVR, the corresponding bit in the IAC Online is set to 1b Reference: 2RJ.116.0 - Book 3 Section 6.7 - Terminal has online capability, TVR and Issuer Action Code-Online check requests an ARQC Conditions: Terminal has online capabilities Issuer Action Codes Denial & Default have all bits set to 0b Issuer Action Code Online has one bit set to 1b and the corresponding TVR bit is set to 1b Terminal Action Code has all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an ARQC in all cases
Page 429
2CJ.161.00 Terminal has online capability, TVR and Online Action Codes check requests a TC (implied)
Test No. 2CJ.161.00 Objective: To ensure that the terminal Issues a GENERATE AC requesting a TC, if terminal has online capabilities, and if for a bit set to 1b in the TVR, the corresponding bit in the IAC Online is set to 0b Reference: 2RJ.116.2 - Book 3 Section 6.7 - Terminal has online capability, TVR and Online Action Codes check requests a TC (implied) Conditions: Terminal has online capabilities Terminal Action Code have all bits set to 0b Issuer Action Codes Denial & Default have all bits set to 0b Issuer Action Code Online has one bit set to 0b and the corresponding TVR bit is set to 1b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting a TC in all cases
Page 430
2CJ.162.00 Terminal is unable to go online, TVR and Issuer Action Code-Default check requests an AAC
Test No. 2CJ.162.00 Objective: To ensure that the terminal issues a second GENERATE AC requesting an AAC, if online connection was requested after first GENERATE AC and terminal is unable to go online and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 1b. Reference: 2RJ.112.2 - Book 3 Section 6.7 - Terminal is unable to go online, TVR and Issuer Action Code-Default check requests an AAC Conditions: Issuer Action Codes Denial have all bits set to 0b LT returns ARQC to first GENERATE AC command Terminal has online capabilities, and was unable to go online Issuer Action Code Default has one bit set to 1b and the corresponding TVR bit is set to 1b Terminal Action Codes have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion In all cases, the LT shall receive a second GENERATE AC command requesting an AAC
Page 431
2CJ.163.00 Terminal is unable to go online, TVR and Default Action Codes check requests a TC
Test No. 2CJ.163.00 Objective: To ensure that the terminal issues a second GENERATE AC requesting an TC, if online connection was requested after first GENERATE AC and terminal is unable to go online and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 0b Reference: 2RJ.117.0 - Book 3 Section 6.7 - Terminal is unable to go online, TVR and Default Action Codes check requests a TC Conditions: Issuer Action Codes Denial have all bits set to 0b LT returns ARQC to first GENERATE AC command Terminal has online capabilities, and was unable to go online Issuer Action Code Default has one bit set to 0b and the corresponding TVR bit is set to 1b Terminal Action Codes have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting a TC in all cases
Page 432
2CJ.164.00 Terminal has not online capability, TVR and Issuer Action Code-Default check requests an AAC
Test No. 2CJ.164.00 Objective: To ensure that the terminal skips the check of Online Action Codes and issues a first GENERATE AC requesting an AAC, if terminal has not rejected the transaction and terminal has no online capabilities and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 1b Reference: 2RJ.120.1 - Book 3 Section 6.7 - Terminal has not online capability, TVR and Issuer Action Code-Default check requests an AAC Conditions: Issuer Action Codes Denial have all bits set to 0b LT returns ARQC to first GENERATE AC command Terminal has no online capabilities Issuer Action Code Default has one bit set to 1b and the corresponding TVR bit is set to 1b Terminal Action Codes have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an AAC in all cases
Page 433
2CJ.165.00 Terminal has not online capability, TVR and Default Action Codes check requests a TC
Test No. 2CJ.165.00 Objective: To ensure that the terminal skips the check of Online Action Codes and issues a first GENERATE AC requesting a TC, if terminal has not rejected the transaction and terminal has no online capabilities and for a bit set to 1b in the TVR, the corresponding bit in the IAC-Default is set to 0b Reference: 2RJ.120.0 - Book 3 Section 6.7 - Terminal has not online capability, TVR and Default Action Codes check requests a TC Conditions: Issuer Action Codes Denial have all bits set to 0b LT returns ARQC to first GENERATE AC command Terminal has no online capabilities Issuer Action Code Default has one bit set to 0b and the corresponding TVR bit is set to 1b Terminal Action Codes has all bit set to 0b AIP must be set to execute the function associated with the TAC bit selected by the tester, and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an TC in all cases
Page 434
Terminal and Issuer Action Analysis

2CJ.166.00 IAC-Denial is not present in the ICC
Test No. 2CJ.166.00 Objective: To ensure that if the Issuer Action Code-Denial does not exist in the card, the terminal uses a default value with all bits set to 0b Reference: 2RJ.107.0 - Book 3 Section 6.7 - Issuer Action Code-Denial is not present in the ICC Conditions: Issuer Action Code Denial does not exist in the card Terminal Action Code Denial has all bits set to 0b Terminal and Issuer Action Codes Online have all bits set to 0b Terminal and Issuer Action Codes Default have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting a cryptogram different from AAC for all tests
Page 435
2CJ.167.00 IAC-Online is not present in the ICC

Test No. 2CJ.167.00 Objective: To ensure that If the Issuer Action Code-Online does not exist in the card, the terminal uses a default value with all bits set to 1b Reference: 2RJ.108.0 - Book 3 Section 6.7 - Issuer Action Code-Online is not present in the ICC Conditions: Issuer Action Code Online does not exist in the card Terminal Action Code Online has all bits set to 0b Terminal and Issuer Action Codes Denial have all bits set to 0b Terminal and Issuer Action Codes Default have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester and the LT will be set so the executed function will fail Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an ARQC
Page 436
2CJ.168.00 IAC-Default is not present in the ICC and the Terminal is unable to go online
Test No. 2CJ.168.00 Objective: To ensure that If the Issuer Action Code-Default does not exist in the card, the terminal uses a default value with all bits set to 1b when the terminal is unable to go online. Reference: 2RJ.109.0 - Book 3 Section 6.7 - Issuer Action Code-Default is not present in the ICC and the Terminal is unable to go online Conditions: Terminal has online capability Issuer Action Code Default does not exist in the card Terminal Action Code Default has all bits set to 0b Issuer and Terminal Action Codes Denial have all bits set to 0b AIP must be set to execute the function associated with the IAC bit selected by the tester and the LT will be set so the executed function will fail LT requests ARQC to first GENERATE AC command Terminal unable to go online (no response received from issuer for instance) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting an AAC in all cases
Page 437
2CJ.169.00 IAC-Default is not present in the ICC and the Terminal is offline only
Test No. 2CJ.169.00 Objective: To ensure that if the Issuer Action Code-Default does not exist in the card, the terminal uses a default value with all bits set to 1b when the terminal is offline only. Reference: 2RJ.109.5 - Book 3 Section 6.7 & Book 3 Section 5.3 - Issuer Action CodeDefault is not present in the ICC and the Terminal is offline only Conditions: Terminal checks Default IAC prior to First Generate AC Issuer Action Code Default does not exist in the card Terminal Action Code Default has all bits set to 0b Issuer and Terminal Action Codes Denial have all bits set to 0b Issuer and Terminal Action Codes Online have all bits set to 0b "AIP must be set to execute a function associated with the IAC and this function will be failed by the LT" (e.g. SDA is failed then the TVR byte 1 bit 7 is set to 1b). Terminal is offline only Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a first GENERATE AC command requesting an AAC in all cases
Page 438
2CJ.169.02 IAC-Default is not present in the ICC and the Terminal is offline only (2)
Test No. 2CJ.169.02 Objective: To ensure that if the Issuer Action Code-Default does not exist in the card, the terminal uses a default value with all bits set to 1b when the terminal is offline only Reference: 2RJ.109.7 - Book 3 Section 6.7 - Issuer Action Code-Default is not present in the ICC and the Terminal is offline only Conditions: Terminal checks Default IAC after First Generate AC Issuer Action Code Default does not exist in the card Terminal Action Code Default has all bits set to 0b Issuer and Terminal Action Code Denial have all bits set to 0b Issuer Action Code Online has all bits set to 1b "AIP must be set to execute a function associated with the IAC and this function will be failed by the LT"(e.g. SDA is failed then the TVR byte 1 bit 7 is set to 1). LT requests ARQC in First Generate AC The terminal is offline only Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting an AAC in all cases
Page 439
2CJ.169.05 Tag for Terminal Capability Profile not include in ICC's CDOL1
Test No. 2CJ.169.05 Objective: To ensure that if Combined DDA / AC Generation is to be performed and the ICC's CDOL 1 does not include the tag for the Terminal Capability Profile, the terminal shall set the bit for Combined DDA / AC Generation Request in the GENERATE AC command to '1'. Reference: 2RJ.122.0 - Book 3 Section 6.7 - Combined DDA/AC Generation Missing Tag Conditions: Terminal and LT support Combined DDA / AC Generation CDOL 1 does not include Terminal Capability Profile Tag CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: TVR byte 1 bit 3 = '1' ie Combined DDA / AC Generation failed
2CJ.170.00 Card Action Analysis function completion

Test No. 2CJ.170.00 Objective: To ensure that the terminal sets the Card Risk Management was performed bit in the TSI to 1b after an ARQC is returned by the card. (Test is not possible for a TC or AAC or AAR since there is no access to TSI) Reference: 2RJ.123.0 - Book 3 Section 6.8 - Card Action Analysis function completion Conditions: LT returns ARQC to first GENERATE AC CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1, bit 6 = 1 ie the Card Risk Management was performed
Page 440
2CJ.175.00 Generate AC Response in a Public Key Envelope

Test No. 2CJ.175.00 Objective: To ensure that if the transaction is eligible for Enhanced Combined DDA/AC and the ICC response is an offline approval (TC) or an online request (ARQC), and if the ICC returns the Generate AC response in a public key envelope as specified in Book 2 Section 6.6, the terminal is able to interpret correctly this response. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC LT answers with a TC or an ARQC to the first Generate AC LT returns its Generate AC response in a public key envelope
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. The terminal shall correctly interpret the LT response.
2CJ.177.00 Advice messages during Card Action Analysis

Test No. 2CJ.177.00 Objective: To ensure that the terminal formats and sends an advice message to the issuer, if the Advice required bit is set to 1b in the Cryptogram Information Data. Reference: 2RJ.125.0 - Book 3 Section 6.8.3 - Advice messages during Card Action Analysis Conditions: LT answers to the Generate AC with the bit 4 of its Cryptogram Information Data (CID) sets to '1'. Terminal supports Advices
Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. The terminal shall format and send an advice.
Page 441
2CJ.178.00 Online Processing function execution

Test No. 2CJ.178.00 Objective: To ensure that the terminal performs the Online Processing function if the card returns an ARQC to the first GENERATE AC Reference: 2RJ.126.0 - Book 3 Section 6.9 - Online Processing function execution Conditions: LT returns an ARQC in response to first GENERATE AC LT must be set so that the terminal will not request an AAC on the first GENERATE AC command
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall prepare and send Authorization or Financial request message for the issuer
Page 442
2CJ.180.00 IAD is received from the Issuer and Issuer Authentication is supported in AIP
Test No. 2CJ.180.00 Objective: To ensure that the terminal issue EXTERNAL AUTHENTICATE command with IAD received if the card supports Issuer Authentication in AIP and if IAD is present in authorization response message Reference: 2RJ.128.0 - Book 3 Section 6.9 - IAD is received from the Issuer and Issuer Authentication is supported in AIP Conditions: LT returns an ARQC in response to first GENERATE AC The LT supports Issuer Authentication (AIP byte 1 bit 3 = 1) Authorization response message contains IAD Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The LT shall receive an EXTERNAL AUTHENTICATE command after the first GENERATE AC Data field of EXTERNAL AUTHENTICATE received by LT shall contain IAD as received from Issuer
Page 443
2CJ.181.00 EXTERNAL AUTHENTICATE unsuccessful

Test No. 2CJ.181.00 Objective: To ensure that the terminal sets the Issuer authentication was unsuccessful bit in the TVR to 1b, if status received from the card in response to EXTERNAL AUTHENTICATE is different from 90 00. Reference: 2RJ.129.0 - Book 3 Section 6.9 - EXTERNAL AUTHENTICATE unsuccessful Conditions: LT returns an ARQC in response to first GENERATE AC The LT supports Issuer Authentication (AIP byte 1 bit 3 = 1) Authorization response message contains IAD LT returns status different from 90 00 in response to EXTERNAL AUTHENTICATE CDOL2 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5, bit 7 = 1 ie Issuer Authentication was unsuccessful
Page 444
2CJ.182.00 IAD is received from the Issuer and Issuer Authentication is not supported in AIP
Test No. 2CJ.182.00 Objective: To ensure that the terminal does not send EXTERNAL AUTHENTICATE command if the card does not support Issuer Authentication in AIP and if IAD is present in authorization response message Reference: 2RJ.130.0 - Book 3 Section 6.9 - IAD is received from the Issuer and Issuer Authentication is not supported in AIP Conditions: LT returns an ARQC in response to first GENERATE AC The LT does not support Issuer Authentication (AIP byte 1 bit 3 = 0) Authorization response message contains IAD Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT shall not receive EXTERNAL AUTHENTICATE command after first GENERATE AC
Page 445
2CJ.183.00 IAD is not received from the Issuer

Test No. 2CJ.183.00 Objective: To ensure that the terminal does not send EXTERNAL AUTHENTICATE command, if the card supports Issuer Authentication in AIP and if IAD is not present in authorization response message Reference: 2RJ.131.0 - Book 3 Section 6.9 - IAD is not received from the Issuer Conditions: LT returns an ARQC in response to first GENERATE AC The LT supports Issuer Authentication (AIP byte 1 bit 3 = 1) Authorization response message does not contain IAD Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT shall not receive EXTERNAL AUTHENTICATE command after first GENERATE AC
Page 446
2CJ.185.00 EXTERNAL AUTHENTICATE performed

Test No. 2CJ.185.00 Objective: To ensure that the terminal sets the Issuer authentication was performed bit in the TSI to 1b, if the EXTERNAL AUTHENTICATE is command is sent to the card Reference: 2RJ.133.0 - Book 3 Section 6.9 - EXTERNAL AUTHENTICATE performed Conditions: LT returns an ARQC in response to first GENERATE AC The LT supports Issuer Authentication (AIP byte 1 bit 3 = 1) Authorization response message contains IAD CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1, bit 5 = 1 ie the Issuer Authentication was performed
Page 447
2CJ.186.00 Multiple Issuer Scripts may be provided with a single authorization response
Test No. 2CJ.186.00 Objective: To ensure that the terminal is able to receive and manage multiple Issuer scripts in a single authorization message Reference: 2RJ.134.0 - Book 3 Section 6.10 - Multiple Issuer Scripts may be provided with a single authorisation response Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains several Issuer scripts LT returns 90 00 to each command of the scripts Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive commands according to the several scripts contained in the authorization response
Page 448
2CJ.187.00 Issuer Script may contain several Issuer Script Commands

Test No. 2CJ.187.00 Objective: To ensure that the terminal is able to receive and manage Issuer scripts containing several commands Reference: 2RJ.135.0 - Book 3 Section 6.10 - Issuer Script may contain several Issuer Script Commands Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with several commands LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands according to the script contained in the authorization response
Page 449
2CJ.188.00 Issuer Script Command unknown to the terminal

Test No. 2CJ.188.00 Objective: To ensure that the terminal is able to deliver unsupported command contained in a script to the card Reference: 2RJ.136.0 - Book 3 Section 6.10 - Issuer Script Command unknown to the terminal Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with several non EMV commands LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of non EMV commands according to the script contained in the authorization response
Page 450
2CJ.189.00 Issuer Script with Tag 71 execution

Test No. 2CJ.189.00 Objective: To ensure that the terminal is processes the script with Tag = 71 before the second GENERATE AC Reference: 2RJ.137.0 - Book 3 Section 6.10 - Issuer Script with Tag 71 execution Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with Tag 71 LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands according to the script contained in the authorization response before the final GENERATE AC
2CJ.190.00 Issuer Script with Tag 72 execution

Test No. 2CJ.190.00 Objective: To ensure that the terminal is processes the script with Tag = 72 after the second GENERATE AC Reference: 2RJ.138.0 - Book 3 Section 6.10 - Issuer Script with Tag 72 execution Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with Tag 72 LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands according to the script contained in the authorization response after the final GENERATE AC
Page 451
2CJ.191.00 Issuer Script Format

Test No. 2CJ.191.00 Objective: To ensure that the terminal is able to recognize a script format ie a constructed data object containing a Script Identifier and a sequence of Issuer Script Command APDUs Reference: 2RJ.139.0 - Book 3 Section 6.10 - Issuer Script Format Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with a script Identifier LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands APDUs according to the script contained in the authorization response
Page 452
2CJ.192.00 Script Identifier in Issuer Script

Test No. 2CJ.192.00 Objective: To ensure that the terminal is able to receive and manage a script without optional Script Identifier. Reference: 2RJ.140.0 - Book 3 Section 6.10 - Script Identifier in Issuer Script Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script without script Identifier LT returns 90 00 to each command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands APDUs according to the script contained in the authorization response
2CJ.193.00 Issuer Script processing

Test No. 2CJ.193.00 Objective: To ensure that the terminal processes scripts in the sequence they appears in authorization response Reference: 2RJ.141.0 - Book 3 Section 6.10 - Issuer Script processing Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains several Issuer script LT returns 90 00 to each command of a script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands APDUs in the order in which scripts were in the authorization response
Page 453
2CJ.194.00 Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 71
Test No. 2CJ.194.00 Objective: To ensure that the terminal sets the Script processing failed before final GENERATE AC bit in the TVR to 1b, if the command contained in the script with Tag 71 received is not BER-TLV encoded with Tag 86 Reference: 2RJ.142.0 - Book 3 Section 6.10 - Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 71 Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains an Issuer script with Tag 71 command in Issuer Script are not BER-TLV encoded in tag 86 CDOL2 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5, bit 6 = 1 ie Script processing failed before final GENERATE AC
Page 454
2CJ.195.00 Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 72
Test No. 2CJ.195.00 Objective: To ensure that the terminal sets the Script processing failed after final GENERATE AC bit in the TVR to 1b, if the command contained in the script with Tag 72 received is not BER-TLV encoded with Tag 86 Reference: 2RJ.143.0 - Book 3 Section 6.10 - Issuer Script Commands not BER-TLV encoded and Issuer Script tag is 72 Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains an Issuer script with Tag 72 command in Issuer Script are not BER-TLV encoded in tag 86 CDOL 2 requests TVR
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5, bit 5 = 1 ie Script processing failed after final GENERATE AC
Page 455
2CJ.196.00 Issuer Script Commands delivery to ICC

Test No. 2CJ.196.00 Objective: To ensure that the terminal processes commands in a script in the sequence they appear in the script Reference: 2RJ.144.0 - Book 3 Section 6.10 - Issuer Script Commands delivery to ICC Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains a script with several commands LT returns 90 00 to each command of a script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a sequence of commands APDUs in the order in which they were in the script received in the authorization response
Page 456
2CJ.197.00 SWI in the Status Code equals 90, 62, or 63

Test No. 2CJ.197.00 Objective: To ensure that the terminal proceeds with the next command in the script if the card returns status code with SW1 equal to 90, 62, or 63 Reference: 2RJ.145.0 - Book 3 Section 6.10 - SWI in the Status Code equals 90, 62, or 63 Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with several commands LT returns 90 00 to script command 1 LT returns 62 xx to script command 2 LT returns 63 xx to script command 3 LT returns 90 00 to other script commands Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive all the commands contained in the script
Page 457
2CJ.198.00 SWI in the Status Code equals 90 or 62, or 63 (implied)

Test No. 2CJ.198.00 Objective: To ensure that the terminal does not set the Script processing failed before final GENERATE AC bit in the TVR to 1b, if SW1 in the status code equals 90 or equals 62, or 63 for the processing of all Issuer script commands Reference: 2RJ.145.1 - Book 3 Section 6.10 - SWI in the Status Code equals 90 or 62, or 63 (implied) Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with several commands LT returns 90 00 to script command 1 LT returns 62 xx to script command 2 LT returns 63 xx to script command 3 LT returns 90 00 to other script commands CDOL2 requests TVR Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5 bit 6 = 0 ie Script processing did not fail before final GENERATE AC (if transactions are batch captured, TVR after final GENERATE AC is in Batch Data Capture Message)
Page 458
2CJ.199.00 SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 71
Test No. 2CJ.199.00 Objective: To ensure that the terminal sets the Script processing failed before final GENERATE AC bit in the TVR to 1b, if Script Tag is 71 and SW1 in the status code returned by the card to a script command is different from 90 or 62, or 63 Reference: 2RJ.146.0 - Book 3 Section 6.10 - SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 71 Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with Tag 71 LT returns SW1 different from 90 or 62, or 63 to one of the script commands CDOL2 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5 bit 6 = 1 ie Script processing failed before final GENERATE AC
Page 459
2CJ.200.00 SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 72
Test No. 2CJ.200.00 Objective: To ensure that the terminal sets the Script processing failed after final GENERATE AC bit in the TVR to 1b, if Script Tag is 72 and SW1 in the status code returned by the card to a script command is different from 90 or 62, or 63 Reference: 2RJ.147.0 - Book 3 Section 6.10 - SWI in the Status Code is different from 90, 62, or 63 and Issuer Script tag is 72 Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with Tag 72 LT returns SW1 different from 90 or 62, or 63 to one of the script commands CDOL 2 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 5, bit 5 = 1 ie Script processing failed after final GENERATE AC
Page 460
2CJ.201.00 Issuer Script processed

Test No. 2CJ.201.00 Objective: To ensure that the terminal sets the Script processing was performed bit in the TSI to 1b, if one script was received in the authorization response and was processed by the terminal Reference: 2RJ.148.0 - Book 3 Section 6.10 - Issuer Script processed Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message contains one Issuer script with Tag 71 CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1 bit 3 = 1 ie Script processing was performed
Page 461
2CJ.202.00 Issuer Script not processed (implied)

Test No. 2CJ.202.00 Objective: To ensure that the terminal does not set the Script processing was performed bit in the TSI to 1b, if no script was received in the authorization response Reference: 2RJ.148.1 - Book 3 Section 6.10 - Issuer Script not processed (implied) Conditions: LT returns an ARQC in response to first GENERATE AC Authorization response message does not contains any Issuer script CDOL2 requests TSI Testers will select a payment scheme EMV AID or a generic AID (eg. Non EMV AID) , in the event of payment scheme interference of the EMV functionality Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TSI byte 1 bit 3 = 0 ie Script processing was not performed
Page 462
2CJ.203.00 Enhanced Combined DDA/AC failed when ICC responded with TC (1)
Test No. 2CJ.203.00 Objective: To ensure that the terminal declines the transaction if ICC has responded st with TC and Enhanced Combined DDA/AC failed (1 Generate AC) Reference: Based on Bulletin N 6 Conditions: CDOL1 in LT does not include Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC LT responds TC to the 1st Generate AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall decline the transaction after the 1st Generate AC.
Page 463
2CJ.203.01 Enhanced Combined DDA/AC failed when ICC responded with TC (2)
Test No. 2CJ.203.01 Objective: To ensure that the terminal declines the transaction if ICC has responded nd with TC and Enhanced Combined DDA/AC failed (2 Generate AC) Reference: Based on Bulletin N 6 Conditions: CDOL1 in LT includes Unpredictable Number generated by the terminal (tag 9F 37) Terminal and LT support Enhanced Combined DDA/AC CDOL2 does not include Unpredictable Number LT responds TC to the 2nd Generate AC LT responds ARQC to the 1st Generate AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC). Pass Criteria: The terminal shall decline the transaction after the 2nd Generate AC.
The following pass criteria only applies if the terminal has the ability to store declined transactions. TVR byte 1, bit 3 shall be set to 1 indicating Combined DDA/AC Generation failed.
Page 464
GENERATE AC Command Coding

2CK.001.00 CDOL1 for the first GENERATE AC
Test No. 2CK.001.00 Objective: To ensure that the terminal is able to build GENERATE AC Data field according to CDOL1 rules Reference: 2RK.001.0 - Book 3 Section 5.2.1 - CDOL1 for the first GENERATE AC Conditions: Different values of CDOL1 are tested
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with Data field correctly filled according to CDOL1
2CK.002.00 CDOL2 for the second GENERATE AC

Test No. 2CK.002.00 Objective: To ensure that the terminal is able to build GENERATE AC Data field according to CDOL2 rules Reference: 2RK.002.0 - Book 3 Section 5.2.1 - CDOL2 for the second GENERATE AC Conditions: different values of CDOL2 are tested First GENERATE AC returns ARQC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a second GENERATE AC command to the LT with Data field correctly filled according to CDOL2
Page 465
2CK.003.00 CDOL requests a TC Hash Value and TDOL is present in the ICC
Test No. 2CK.003.00 Objective: To ensure that if TC Hash Value is requested in CDOL, the terminal is able to calculate TC Hash value according to the TDOL provided by the card Reference: 2RK.003.0 - Book 3 Section 5.2.2 - CDOL requests a TC Hash Value and TDOL is present in the ICC Conditions: LT contains TDOL CDOL1 requests TC Hash value Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with Data field containing a TC Hash value correctly calculated
Page 466
2CK.004.00 CDOL requests a TC Hash Value and TDOL is not present in the ICC
Test No. 2CK.004.00 Objective: To ensure that if TC Hash Value is requested in CDOL, and TDOL is not provided by the card, the terminal is able to calculate TC Hash value according to the default TDOL contained in the terminal and it sets the Default TDOL used bit in the TVR to 1b Reference: 2RK.004.0 - Book 3 Section 5.2.2 - CDOL requests a TC Hash Value and TDOL is not present in the ICC Conditions: LT does not contains TDOL CDOL1 requests TC Hash value and TVR Terminal contains a default value for TDOL (value is known) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with Data field containing a TC Hash value correctly calculated with default TDOL as input TVR byte 5, bit 8 = 1 ie Default TDOL used
Page 467
2CK.005.00 CDOL requests a TC Hash Value and neither TDOL nor default TDOL is present
Test No. 2CK.005.00 Objective: To ensure that if TC Hash Value is requested in CDOL, and TDOL is not provided by the card and there is no default TDOL in terminal, the terminal is able to calculate TC Hash value using a TDOL with no data object. Reference: 2RK.005.0 - Book 3 Section 5.2.2 - CDOL requests a TC Hash Value and neither TDOL nor default TDOL is present Conditions: LT does not contains TDOL CDOL1 requests TC Hash value, and TVR Terminal does not contains a default value for TDOL Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a GENERATE AC command to the LT with Data field containing a TC Hash value correctly calculated with a TDOL with no entry TVR byte 5, bit 8 = 0 ie Default TDOL not used
Page 468
2CK.006.00 CDOL requests a TC Hash Value during the second GENERATE AC

Test No. 2CK.006.00 Objective: To ensure that if TC Hash Value is requested in CDOL2, the terminal ensure that the data provided in the TC Hash value is current at the time the command is issued Reference: 2RK.006.0 - Book 3 Section 5.2.2 - CDOL requests a TC Hash Value during the second GENERATE AC Conditions: LT contains TDOL TDOL requests TSI CDOL1 requests TSI CDOL2 requests TSI and TC Hash value LT returns ARQC to first GENERATE AC Issuer Authentication is supported and performed Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall return a second GENERATE AC command to the LT with Data field containing a TC Hash value correctly calculated (in particular with TSI with Issuer Authentication was performed bit set) TSI returned in first GENERATE AC byte 1, bit 5 = 0 ie Issuer Authentication was not performed TSI returned in second GENERATE AC byte 1, bit 5 = 1 ie Issuer Authentication was performed
Page 469
2CK.007.00 Terminal requests a TC on first GENERATE AC

Test No. 2CK.007.00 Objective: To ensure that if the terminal requests a TC in first GENERATE AC, it supports AAC, or ARQC or TC or AAR in the response from the card Reference: 2RK.007.0 - Book 3 Section 5.3.1 - Terminal requests a TC on first GENERATE AC Conditions: IAC and TAC set so that Terminal requests TC on first GENERATE AC LT returns AAC, or ARQC or TC or AAR in the response to first GENERATE AC (4 tests) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion according to the type of cryptogram received.
2CK.008.00 Terminal requests an ARQC on first GENERATE AC

Test No. 2CK.008.00 Objective: To ensure that if the terminal requests an ARQC in first GENERATE AC, it supports AAC, or ARQC or AAR in the response from the card Reference: 2RK.008.0 - Book 3 Section 5.3.1 - Terminal requests an ARQC on first GENERATE AC Conditions: IAC and TAC set so that Terminal requests ARQC on first GENERATE AC LT returns AAC, or ARQC or AAR in the response to first GENERATE AC (3 tests) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion according to the type of cryptogram received.
Page 470
2CK.009.00 Terminal requests an AAC on first GENERATE AC

Test No. 2CK.009.00 Objective: To ensure that if the terminal requests an AAC in first GENERATE AC, it supports AAC in the response from the card Reference: 2RK.009.0 - Book 3 Section 5.3.1 - Terminal requests an AAC on first GENERATE AC Conditions: IAC and TAC set so that Terminal requests AAC on first GENERATE AC LT returns AAC in the response to first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion according to the type of cryptogram received.
2CK.010.00 Card responds with an ARQC on first GENERATE AC

Test No. 2CK.010.00 Objective: To ensure that if the card responds with an ARQC to first GENERATE AC and is permitted to do so and if terminal has online capability, the terminal prepares and sends an authorization or financial request message Reference: 2RK.010.0 - Book 3 Section 5.3.1 - Card responds with an ARQC on first GENERATE AC Conditions: All Action Code Denial bits are set to 0b to prevent the terminal from requesting an AAC on the first GENERATE AC LT returns ARQC in the response to first GENERATE AC Terminal has online capability Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall prepare and send an authorization or financial request message.
Page 471
2CK.011.00 Card responds with an AAR on first GENERATE AC

Test No. 2CK.011.00 Objective: To ensure that if the card responds with an AAR to first GENERATE AC and is permitted to do so, the terminal either provides an Authorization Response Code and proceeds to the completion function or use the AAR to go online Reference: 2RK.011.0 - Book 3 Section 5.3.1 - Card responds with an AAR on first GENERATE AC Conditions: LT returns AAR in the response to first GENERATE AC CDOL2 requests Authorization Response Code Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: If Terminal uses AAR to go online, The terminal shall either prepare and send an authorization or financial request message with AAR instead of ARQC If Terminal proceeds offline, the LT shall receive a second GENERATE AC with cryptogram requested in accordance with Authorization Response Code provided by the terminal
Page 472
2CK.012.00 Card responds with a TC on first GENERATE AC

Test No. 2CK.012.00 Objective: To ensure that if the card responds with a TC to first GENERATE AC and is permitted to do so, the terminal completes the transaction offline (accepted) Reference: 2RK.011.1 - Book 3 Section 5.3.1 - Card responds with a TC on first GENERATE AC Conditions: All Action Codes have all bits set to 0b LT returns TC in the response to first GENERATE AC
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall complete the transaction offline (accepted).
2CK.013.00 Card responds with a AAC on first GENERATE AC

Test No. 2CK.013.00 Objective: To ensure that if the card responds with an AAC to first GENERATE AC, the terminal completes the transaction offline (declined) Reference: 2RK.011.2 - Book 3 Section 5.3.1 - Card responds with a AAC on first GENERATE AC Conditions: LT returns AAC in the response to first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall complete the transaction offline (declined).
Page 473
2CK.015.00 Terminal requests an AAC on second GENERATE AC

Test No. 2CK.015.00 Objective: To ensure that if the terminal requests an AAC in second GENERATE AC, it supports AAC, in the response from the card and considers any other cryptogram as an AAC Reference: 2RK.013.0 - Book 3 Section 5.3.2 - Terminal requests an AAC on second GENERATE AC Conditions: IAC set so that Terminal requests ARQC on first GENERATE AC LT returns AAC, or TC or AAR or ARQC in the response to second GENERATE AC (4 tests) Host Source shall return denial response in the authorization response Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion according to the type of cryptogram received (declined in all cases).
2CK.017.00 Cryptogram at a higher level than requested (1)

Test No. 2CK.017.00 Objective: To ensure that the terminal terminates the transaction if the card responds with a cryptogram with higher level than one requested in first GENERATE AC Reference: 2RK.015.0 - Book 3 Section 5.3 - Cryptogram at a higher level than requested (1) Conditions: LT returns TC to first GENERATE AC requesting AAC or ARQC LT returns TC or ARQC to first GENERATE AC requesting AAC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: In all cases, the terminal shall terminate the transaction
Page 474
2CK.018.00 Cryptogram at a higher level than requested (2)

Test No. 2CK.018.00 Objective: To ensure that the terminal completes the transaction and consider the cryptogram as an AAC if the card responds with a cryptogram with higher level than one requested in second GENERATE AC Reference: 2RK.016.0 - Book 3 Section 5.3 - Cryptogram at a higher level than requested (2) 2RK.012.0 - Book 3 Section 5.3.2 - Terminal requests a TC on second GENERATE AC Conditions: LT returns TC or ARQC to second GENERATE AC requesting AAC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: In all cases, the terminal shall complete the transaction and consider the cryptogram as an AAC (declined)
Erroneous or missing Data in ICC

2CL.001.00 Mandatory data objects missing: FCI
Test No. 2CL.001.00 Objective: To ensure that the terminal terminates the transaction if mandatory FCI is missing in a response to SELECT command Reference: 2RL.001.0 - Book 1 Section 7.3.4 - Mandatory data objects missing: FCI Conditions: LT response to SELECT does not contains FCI Tag Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 475
2CL.002.00 Mandatory data objects missing: DF Name

Test No. 2CL.002.00 Objective: To ensure that if the terminal supports PSE selection and mandatory DF Name is missing in a response to SELECT PSE or DDF command, it terminates the transaction Reference: 2RL.001.1 - Book 1 Section 7.3.4 - Mandatory data objects missing: DF Name Conditions: Terminal supports selection with PSE LT response to SELECT PSE or DDF does not contains DF Name Tag Procedure: Application selection with PSE process is performed by the LT Pass Criteria: The terminal shall terminate the transaction
2CL.003.00 Mandatory data objects missing: SFI

Test No. 2CL.003.00 Objective: To ensure that if the terminal supports selection with PSE and mandatory SFI is missing in a response to SELECT PSE or DDF command, it terminates the transaction. Reference: 2RL.001.2 - Book 1 Section 7.3.4 - Mandatory data objects missing: SFI Conditions: Terminal supports PSE LT response to SELECT PSE or DDF does not contains SFI Tag Procedure: Application selection process with PSE is performed by the LT Pass Criteria: The terminal shall terminate the transaction
Page 476
2CL.003.05 Mandatory data objects missing: DDF Name

Test No. 2CL.003.05 Objective: To ensure that if the terminal supports selection with PSE and mandatory DDF Name is missing in a response to SELECT PSE or DDF command, it terminates the transaction. Reference: 2RL.001.21 - Book 1 Section 8.2.3 - Mandatory data objects missing: DDF Name Conditions: Terminal supports PSE LT response to SELECT PSE or DDF does not contain DDF Name Procedure: Application selection process with PSE is performed by the LT Pass Criteria: The terminal shall terminate the transaction
2CL.004.00 Mandatory data objects missing: ADF Name

Test No. 2CL.004.00 Objective: To ensure that the terminal terminates the transaction if mandatory ADF Name is missing in a response to SELECT ADF command Reference: 2RL.001.3 - Book 1 Section 8.2.3 - Mandatory data objects missing: ADF Name Conditions: LT response to SELECT ADF does not contains DF Name Tag Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate the transaction
Page 477
2CL.005.00 Mandatory data objects missing: Application Label

Test No. 2CL.005.00 Objective: To ensure that the terminal terminates the transaction if mandatory Application Label is missing from an ADF while the terminal is reading the PSE. Reference: 2RL.001.4 - Book 1 Section 7.3.4 - Mandatory data objects missing: Application Label Conditions: Terminal supports PSE Application Label is missing from the ADF while the terminal reads the PSE Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate the transaction
2CL.006.00 Mandatory data objects missing: FCI Proprietary Template

Test No. Objective: Reference: Conditions: Procedure: Pass Criteria: 2CL.006.00 To ensure that the terminal terminates the transaction if mandatory FCI Proprietary Template is missing in a response to SELECT command 2RL.001.5 - Book 1 Section 7.3.4 - Mandatory data objects missing: FCI Proprietary Template LT response to SELECT does not contains FCI Proprietary Template Tag Application selection process is performed by the LT The terminal shall terminate the transaction
Page 478
2CL.007.00 Mandatory data objects missing: AFL

Test No. 2CL.007.00 Objective: To ensure that the terminal terminates the transaction if mandatory AFL is missing in a response to GET PROCESSING OPTIONS command Reference: 2RL.001.6 - Book 3 Section 3.4 & Book 3 Section 3.3 - Mandatory data objects missing: AFL Conditions: LT response to GET PROCESSING OPTIONS does not contains AFL Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CL.008.00 Mandatory data objects missing: AIP

Test No. 2CL.008.00 Objective: To ensure that the terminal terminates the transaction if mandatory AIP is missing in a response to GET PROCESSING OPTIONS command Reference: 2RL.001.7 - Book 3 Section 3.4 & Book 3 Section 3.3 - Mandatory data objects missing: AIP Conditions: LT response to GET PROCESSING OPTIONS does not contains AIP Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 479
2CL.009.00 Mandatory data objects missing: CDOL1

Test No. 2CL.009.00 Objective: To ensure that the terminal terminates the transaction if mandatory CDOL1 is missing in the card Reference: 2RL.001.8 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory data objects missing: CDOL1 Conditions: LT does not contains CDOL1 Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CL.010.00 Mandatory data objects missing: CDOL2

Test No. 2CL.010.00 Objective: To ensure that the terminal terminates the transaction if mandatory CDOL2 is missing in the card Reference: 2RL.001.9 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory data objects missing: CDOL2 Conditions: LT does not contains CDOL2 Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 480
2CL.011.00 Mandatory data objects missing: PAN

Test No. 2CL.011.00 Objective: To ensure that the terminal terminates the transaction if mandatory PAN is missing in the card Reference: 2RL.001.10 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory data objects missing: PAN Conditions: LT does not contains PAN
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
2CL.012.00 Mandatory data objects missing: Application Expiration Date

Test No. 2CL.012.00 Objective: To ensure that the terminal terminates the transaction if mandatory Application Expiration Date is missing in the card Reference: 2RL.001.11 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory data objects missing: Application Expiration Date Conditions: LT does not contains Application Expiration Date
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction
Page 481
2CL.013.00 ATC not returned by GET DATA and Both LCOL and UCOL are present
Test No. 2CL.013.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if both Lower and Upper Consecutive Offline Limit data objects are present in the ICC and if the ATC is not returned by the GET DATA. Reference: 2RL.003.0 - Book 3 Section 3.4 - ATC not returned by GET DATA and Both LCOL and UCOL are present Conditions: LT supports Terminal Risk Management (AIP Byte 1 bit 4 = '1') Terminal shall support Risk management Lower and Upper Consecutive Offline Limit are present in LT ATC is not returned by GET DATA CDOL1 Requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TVR byte 2, bit 4 = 0 ie not a new card
Page 482
2CL.014.00 Last Online ATC Register not returned by GET DATA and Both LCOL and UCOL are present
Test No. 2CL.014.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if both Lower and Upper Consecutive Offline Limit data objects are present in the ICC and if the Last Online ATC is not returned by the GET DATA. Reference: 2RL.004.0 - Book 3 Section 3.4 - Last Online ATC Register not returned by GET DATA and Both LCOL and UCOL are present Conditions: LT supports Terminal Risk Management (AIP byte 1 bit 4= '1') Terminal shall support Risk management Lower and Upper Consecutive Offline Limit are present in LT Last Online ATC is not returned by GET DATA CDOL1 Requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TVR byte 2, bit 4 = 0 ie not a new card
Page 483
2CL.015.00 CVM List not present and Cardholder Verification is supported in AIP
Test No. 2CL.015.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Cardholder verification is supported in AIP and CVM List is missing in the card. Reference: 2RL.005.0 - Book 3 Section 3.4 - CVM List not present and Cardholder Verification is supported in AIP Conditions: AIP byte 1 bit 5 = 1 (Cardholder verification supported) CVM List is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 484
2CL.016.00 CA Public Key Index not present and Offline SDA is supported in AIP
Test No. 2CL.016.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Offline Static Data Authentication is supported in AIP and Certification Authority Public Key Index is missing in the card. Reference: 2RL.006.0 - Book 3 Section 3.4 - Certification Authority Public Key Index not present and Offline SDA is supported in AIP Conditions: Terminal supports static data authentication AIP byte 1 bit 7 = 1 (Offline Static Data Authentication supported) Certification Authority Public Key Index is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 485
2CL.017.00 CA Public Key Index not present and Offline DDA is supported in AIP
Test No. 2CL.017.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Offline Dynamic Data Authentication is supported in AIP and Certification Authority Public Key Index is missing in the card. Reference: 2RL.007.0 - Book 3 Section 3.4 - Certification Authority Public Key Index not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) Certification Authority Public Key Index is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 486
2CL.019.00 Issuer Public Key Certificate not present and Offline SDA is supported in AIP
Test No. 2CL.019.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Offline Static Data Authentication is supported in AIP and Issuer Public Key Certificate is missing in the card. Reference: 2RL.009.0 - Book 3 Section 3.4 - Issuer Public Key Certificate not present and Offline SDA is supported in AIP Conditions: Terminal supports static data authentication AIP byte 1 bit 7 = 1 (Offline Static Data Authentication supported) Issuer Public Key Certificate is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 487
2CL.020.00 Issuer Public Key Certificate not present and Offline DDA is supported in AIP
Test No. 2CL.020.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Offline Dynamic Data Authentication is supported in AIP and Issuer Public Key Certificate is missing in the card. Reference: 2RL.010.0 - Book 3 Section 3.4 - Issuer Public Key Certificate not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) Issuer Public Key Certificate is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 488
2CL.021.00 Issuer Public Key Exponent not present and Offline SDA is supported in AIP
Test No. 2CL.021.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b if Offline Static Data Authentication is supported in AIP and Issuer Public Key Exponent is missing in the card. Reference: 2RL.011.0 - Book 3 Section 3.4 - Issuer Public Key Exponent not present and Offline SDA is supported in AIP Conditions: Terminal supports static data authentication AIP byte 1 bit 7 = 1 (Offline Static Data Authentication supported) Issuer Public Key Exponent is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 489
2CL.022.00 Issuer Public Key Exponent not present and Offline DDA is supported in AIP
Test No. 2CL.022.00 Objective: To ensure that terminal sets ICC data missing bit in the TVR to 1b if Offline Dynamic Data Authentication is supported in AIP and Issuer Public Key Exponent is missing in the card. Reference: 2RL.012.0 - Book 3 Section 3.4 - Issuer Public Key Exponent not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) Issuer Public Key Exponent is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 490
2CL.023.00 Issuer Public Key Remainder not present and Offline SDA is supported in AIP
Test No. 2CL.023.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b, if Offline Static Data Authentication is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should be present. Reference: 2RL.013.0 - Book 3 Section 3.4 - Issuer Public Key Remainder not present and Offline SDA is supported in AIP Conditions: Terminal supports static data authentication AIP byte 1 bit 7 = 1 (Offline Static Data Authentication supported) Issuer Public Key Remainder is not present in LT Size of Issuer Public Key and CA Public Key is such as NI > NCA 36 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 491
2CL.024.00 Issuer Public Key Remainder not present and Offline DDA is supported in AIP
Test No. 2CL.024.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b , if Offline Dynamic Data Authentication is supported in AIP and Issuer Public Key Remainder is missing in the card and the length of the recovered Issuer Public Key indicates that Issuer Public Key Remainder should be present. Reference: 2RL.014.0 - Book 3 Section 3.4 - Issuer Public Key Remainder not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) Issuer Public Key Remainder is not present in LT Size of Issuer Public Key and CA Public Key is such as NI > NCA 36 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 492
2CL.025.00 Signed Static Application Data not present and Offline SDA is supported in AIP
Test No. 2CL.025.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b , if Offline Static Data Authentication is supported in AIP and Signed Static Application Data is missing in the card. Reference: 2RL.015.0 - Book 3 Section 3.4 - Signed Static Application Data not present and Offline SDA is supported in AIP Conditions: Terminal supports static data authentication AIP byte 1 bit 7 = 1 (Offline Static Data Authentication supported) Signed Static Application Data is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 493
2CL.026.00 ICC Public Key Certificate not present and Offline DDA is supported in AIP
Test No. 2CL.026.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b , if Offline Dynamic Data Authentication is supported in AIP and ICC Public Key Certificate is missing in the card. Reference: 2RL.016.0 - Book 3 Section 3.4 - ICC Public Key Certificate not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) ICC Public Key Certificate is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 494
2CL.027.00 ICC Public Key Exponent not present and Offline DDA is supported in AIP
Test No. 2CL.027.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b , if Offline Dynamic Data Authentication is supported in AIP and ICC Public Key Exponent is missing in the card. Reference: 2RL.017.0 - Book 3 Section 3.4 - ICC Public Key Exponent not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) ICC Public Key Exponent is not present in LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 495
2CL.028.00 ICC Public Key Remainder not present and Offline DDA is supported in AIP
Test No. 2CL.028.00 Objective: To ensure that terminal sets the ICC data missing bit in the TVR to 1b , if Offline Dynamic Data Authentication is supported in AIP and ICC Public Key Remainder is missing in the card and the length of the recovered ICC Public Key indicates that ICC Public Key Remainder should be present. Reference: 2RL.018.0 - Book 3 Section 3.4 - ICC Public Key Remainder not present and Offline DDA is supported in AIP Conditions: Terminal supports dynamic data authentication AIP byte 1 bit 6 = 1 (Offline Dynamic Data Authentication supported) ICC Public Key Remainder is not present in LT Size of ICC Public Key and Issuer Public Key is such as NICC > NI 42 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion. TVR byte 1, bit 6 = 1 ie ICC Data missing
Page 496
2CL.029.00 Constructed Data Objects do not parse correctly: FCI of PSE

Test No. 2CL.029.00 Objective: To ensure that if the terminal supports selection with PSE and FCI of PSE template does not parse correctly, it terminates the processing. Reference: 2RL.019.0 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: FCI of PSE Conditions: Terminal supports selection with PSE FCI returned in response to SELECT PSE does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application selection process with PSE is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.029.05 Constructed Data Objects do not parse correctly: Directory Record in Payment System Directory
Test No. 2CL.029.05 Objective: To ensure that if Directory Record in Payment System Directory does not parse correctly, the terminal terminates the processing. Reference: 2RL.019.07 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: Directory Record in Payment System Directory Conditions: Terminal supports SELECT PSE The Record returned in response to Read Directory command does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application selection process with PSE is performed by the LT. Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction.
Page 497
2CL.030.00 Constructed Data Objects do not parse correctly: Record Template

Test No. 2CL.030.00 Objective: To ensure that the terminal terminates the processing if record template does not parse correctly Reference: 2RL.019.1 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: Record Template Conditions: Record template returned in response to READ RECORD does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.031.00 Constructed Data Objects do not parse correctly: Application Template

Test No. 2CL.031.00 Objective: To ensure that if the terminal supports selection with PSE and Application template does not parse correctly in directory, it terminates the processing Reference: 2RL.019.2 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: Application Template Conditions: Terminal supports selection with PSE Application templates read in Directory file do not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application selection process with PSE is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 498
2CL.032.00 Constructed Data Objects do not parse correctly: FCI of ADF

Test No. 2CL.032.00 Objective: To ensure that the terminal terminates the processing if FCI of ADF template does not parse correctly Reference: 2RL.019.3 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: FCI of ADF Conditions: FCI of ADF template returned in response to SELECT ADF does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.033.00 Constructed Data Objects do not parse correctly: GPO response template
Test No. 2CL.033.00 Objective: To ensure that the terminal terminates the Processing if GET PROCESSING OPTIONS response template does not parse correctly Reference: 2RL.019.4 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: GPO response template Conditions: GET PROCESSING OPTIONS response template returned in response to GET PROCESSING OPTIONS does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 499
2CL.034.00 Constructed Data Objects do not parse correctly: GENERATE AC response template
Test No. 2CL.034.00 Objective: To ensure that the terminal terminates the processing if GENERATE AC response template does not parse correctly Reference: 2RL.019.5 - Book 3 Section 3.4 & Section 2.5.5.4 - Constructed Data Objects do not parse correctly: Generate AC response template Conditions: GENERATE AC response template returned in response to GENERATE AC does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.035.00 Constructed Data Objects do not parse correctly: INTERNAL AUTHENTICATE response template
Test No. 2CL.035.00 Objective: To ensure that the terminal terminates the processing if INTERNAL AUTHENTICATE response template does not parse correctly Reference: 2RL.019.6 - Book 3 Section 3.4 & Section 2.5.9.4 - Constructed Data Objects do not parse correctly: Internal Authenticate response template Conditions: INTERNAL AUTHENTICATE response template returned in response to INTERNAL AUTHENTICATE does not parse correctly (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Terminal and LT support DDA Procedure: Application in LT is selected and transaction is processed with LT (in particular Dynamic Data Authentication) Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 500
2CL.036.00 Dates are out of the range

Test No. 2CL.036.00 Objective: To ensure that the terminal terminates the processing if dates provided by the card are out of range Reference: 2RL.020.0 - Book 3 Section 3.4 - Dates are out of the range Conditions: Date contained in LT are out of range (test can be made with several mistakes: for instance day outside 01-31, month outside 01-12) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.037.00 Data that must be in a specific range of values but are not: SFI
Test No. 2CL.037.00 Objective: To ensure that if the terminal supports selection with PSE and SFI value returned by the card in FCI is not in the range of supported values, it terminates the processing. Reference: 2RL.021.0 - Book 1 Section 8.2.3 - Data that must be in a specific range of values but are not: SFI Conditions: Terminal supports selection with PSE SFI of Directory File returned by the LT is outside range 01-10 Procedure: Application selection process with PSE is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 501
2CL.038.00 Data that must be in a specific range of values but are not: Issuer Code Table Index
Test No. 2CL.038.00 Objective: To ensure that the terminal terminates the processing if Issuer Code Table Index value is not in the range of supported values Reference: 2RL.021.1 - Book 3 Section 3.4 & Book 3 Annex C.4 - Data that must be in a specific range of values but are not: Issuer Code Table Index Conditions: Issuer Code Table Index value returned by the LT in FCI is outside ISO 8959 supported values Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.044.00 CVM List with no Cardholder Verification Rules

Test No. 2CL.044.00 Objective: To ensure that the terminal terminates the processing if the CVM List does not contain any Cardholder Verification Rule Reference: 2RL.022.0 - Book 3 Section 3.4 - CVM List with no Cardholder Verification Rules Conditions: CVM List in LT does not contain any Cardholder Verification Rule (empty) Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 502
2CL.046.00 AFL with no entries

Test No. 2CL.046.00 Objective: To ensure that the terminal terminates the processing if the AFL does not contain any entry Reference: 2RL.024.0 - Book 3 Section 3.4 - AFL with no entries Conditions: AFL returned by the LT does not contain any entry (empty) Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.047.00 AFL with an incorrect SFI

Test No. 2CL.047.00 Objective: To ensure that the terminal terminates the processing if an SFI in the AFL has a value of 0 or 31 Reference: 2RL.025.0 - Book 3 Section 3.4 - AFL with an incorrect SFI Conditions: Test 1: SFI in AFL is 0 Test 2: SFI in AFL is 31 Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 503
2CL.048.00 AFL with an incorrect starting record number

Test No. 2CL.048.00 Objective: To ensure that the terminal terminates the processing if a start record number in AFL has a value of 0 Reference: 2RL.026.0 - Book 3 Section 3.4 - AFL with an incorrect starting record number Conditions: Start record number in AFL has a value of 0 Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.049.00 AFL with an incorrect ending record number

Test No. 2CL.049.00 Objective: To ensure that the terminal terminates the processing if a start record number in AFL has a value greater than the ending record Reference: 2RL.027.0 - Book 3 Section 3.4 - AFL with an incorrect ending record number Conditions: Start record number in AFL has a value greater than ending record Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
Page 504
2CL.050.00 AFL with an incorrect number of records participating in Offline Data Authentication
Test No. 2CL.050.00 Objective: To ensure that the terminal terminates the processing if an entry in AFL has an incorrect number of records participating in Offline Data Authentication. Reference: 2RL.028.0 - Book 3 Section 3.4 - AFL with an incorrect number of records participating in Offline Data Authentication Conditions: Ending record number - start record number + 1< number of records participating in Offline Data Authentication Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall terminate processing and can return to application selection or abort the transaction
2CL.052.00 ISO Padding: right padding

Test No. 2CL.052.00 Objective: To ensure that a terminal ignores the padding if a Data Element is right padded with padding bytes 0x00 or 0xFF. Reference: 2RL.030.0 - Book 3 Section 1.2 - ISO Padding: right padding Conditions: Some Data Templates returned by the LT contains right padding. Test is made with padding bytes 0x00 and 0xFF and for several templates: FCI, record...). Length of padding bytes is not included in the template length Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall process the transaction until completion
Page 505
2CL.053.00 ISO Padding: padding before Data object

Test No. 2CL.053.00 Objective: To ensure that a terminal ignores the padding with if a Data Element is padded left with padding bytes 0x00 or 0xFF. Reference: 2RL.031.0 - Book 3 Section 1.2 - ISO Padding: padding before Data object Conditions: Some Data Templates returned by the LT contains left padding (before the template). Test is made with padding bytes 0x00 and 0xFF and for several templates: FCI, record...). Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall process the transaction until completion
2CL.054.00 ISO Padding: padding between Data object

Test No. 2CL.054.00 Objective: To ensure that a terminal ignores the padding with if there is padding with bytes 0x00 or 0xFF between 2 Data Elements in a Template Reference: 2RL.032.0 - Book 3 Section 1.2 - ISO Padding: padding between Data object Conditions: Some Data Templates returned by the LT contains padding between Data Elements of the template. Test is made with padding bytes 0x00 and 0xFF and for several templates: FCI, record...). Length of padding bytes is included in the template length Procedure: Application selection process is performed by the LT Pass Criteria: The terminal shall process the transaction until completion
Page 506
ICC Terminal Specification for Payment System, Test Case Description

General Requirements
2CM.001.00 Merchant-controlled Terminal Provides Amount
Test No. 2CM.001.00 Objective: To ensure that the terminal provides the amount of the transaction during Initiate Application Processing if PDOL includes amount field Reference: 2RM.001.0 - Book 4 Section 2.3.1 - Merchant-controlled Terminal Provides Amount Conditions: PDOL requests Amount, Authorized Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a GET PROCESSING OPTIONS with data field containing the amount of the transaction
Page 507
2CM.002.00 Merchant-controlled Terminal Obtains Amount if Not Available

Test No. 2CM.002.00 Objective: To ensure that the terminal displays the Enter Amount message and obtains the amount of the transaction, during Initiate Application Processing if PDOL includes amount field and it is not yet available Reference: 2RM.002.0 - Book 4 Section 2.3.1 - Merchant-controlled Terminal Obtains Amount if Not Available Conditions: PDOL requests Amount, Authorized terminal is a merchant controlled terminal Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a GET PROCESSING OPTIONS with data field containing the amount of the transaction The Terminal should display the Enter Amount message
2CM.003.00 Card Returns Error in Response to GET PROCESSING Command

Test No. 2CM.003.00 Objective: To ensure that the terminal returns to application selection if the GET PROCESSING OPTIONS returns 69 85 for the selected application Reference: 2RM.003.0 - Book 4 Section 2.3.1 - Card Returns Error in Response to GET PROCESSING Command Conditions: GET PROCESSING OPTIONS returns 69 85 Terminal and LT have at least 2 mutually supported applications Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The LT shall receive a SELECT command for the next supported application after having returned 69 85 to the GET PROCESSING OPTIONS command
Page 508
2CM.004.00 Online Only Terminal Not Supporting Data Authentication Sets Bit
Test No. 2CM.004.00 Objective: To ensure that an online only terminal sets the Offline Data Authentication was not performed bit in the TVR to 1b , if it does not support any form of Data authentication according to the Terminal capabilities Reference: 2RM.004.0 - Book 4 Section 2.3.1 - Online Only Terminal Not Supporting Data Authentication Sets Bit Conditions: Terminal capabilities indicates Authentication are not supported Terminal is online only terminal CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: TVR byte 1, bit 8 = 1 ie Data Authentication was not performed that Static and Dynamic Data
Page 509
2CM.006.00 Card and Terminal Application Version Numbers are different

Test No. 2CM.006.00 Objective: To ensure that if the card and terminal Application Version Numbers are different, the terminal attempts to continue processing the transaction. If it is unable to continue, the terminal aborts the transaction. Reference: 2RM.006.0 - Book 4 Section 2.3.3 - Card and Terminal Application Version Numbers are different Conditions: LT and terminal have different Application Version Number CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall attempt to process the transaction until completion, if unable the terminal shall abort the transaction. TVR byte 2, bit 8 = 1 ie ICC and terminal have different application versions
Page 510
2CM.009.00 Terminal Recognition of CVM Codes ('No CVM required' supported)

Test No. 2CM.009.00 Objective: To ensure that the terminal recognizes CVM code No CVM required if the terminal supports this CVM Reference: 2RM.009.0 - Book 4 Section 2.3.4 - Terminal Recognition of CVM Codes. ('No CVM required' supported) Conditions: LT supports Cardholder verification Terminal supports 'No CVM required'. CDOL1 requests TVR, TSI and CVM results CVM List is 'No CVM required, always' Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie cardholder verification succeeded The terminal shall set byte 3 of the CVM Results to successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 511
2CM.009.05 Terminal Recognition of CVM Codes ('No CVM required' not supported)
Test No. 2CM.009.05 Objective: To ensure that the terminal recognizes CVM code No CVM required if the terminal does not support this CVM. Reference: 2RM.009.5 - Book 4 Section 2.3.4 - Terminal Recognition of CVM Codes ( 'No CVM required' not supported) Conditions: LT supports Cardholder verification Terminal does not support 'No CVM required'. CDOL1 requests TVR, TSI and CVM results CVM List is 'No CVM required, always' Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie cardholder verification was not successful The terminal shall set byte 3 of the CVM Results to not successful TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
Page 512
2CM.010.00 Terminal Recognition of CVM Codes ('Fail CVM processing')

Test No. 2CM.010.00 Objective: To ensure that the terminal recognizes CVM code Fail CVM Reference: 2RM.009.1 - Book 4 Section 2.3.4 - Terminal Recognition of CVM Codes ('Fail CVM processing') Conditions: LT supports Cardholder verification CVM List is 'Fail CVM, always' CDOL1 requests TSI and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall set byte 3 of the CVM Results to failed TSI byte 1, bit 7 = 1 ie Cardholder verification was performed
2CM.011.00 Supported CVM

Test No. 2CM.011.00 Objective: To ensure that CVM supported by the terminal are indicated in terminal capabilities Reference: 2RM.009.2 - Book 4 Section 2.3.4 - Supported CVM Conditions: PDOL requests Terminal capabilities Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal capabilities returned by terminal shall reflect the CVM supported by the terminal
Page 513
2CM.012.00 PIN Try Counter

Test No. 2CM.012.00 Objective: To ensure that the terminal issue a GET DATA command to retrieve the PIN Try Counter if applicable CVM is offline PIN. Reference: 2RM.010.0 - Book 4 Section 2.3.4.1 - PIN Try Counter Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification Terminal supports GET DATA for PIN Try Counter Test 1: CVM List is 'Plaintext PIN, always' Test 2: CVM List is 'Enciphered PIN, always' Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT shall receive a GET DATA command (80 CA 9F 17) before receiving the VERIFY command (test 1) or before receving a GET CHALLENGE command (test 2).
Page 514
2CM.013.00 PIN Try Counter Not Retrievable by ICC

Test No. 2CM.013.00 Objective: To ensure that the terminal prompts for PIN entry if PIN Try Counter is not retrievable or GET DATA is not supported by LT. Reference: 2RM.011.0 - Book 4 Section 2.3.4.1 - PIN Try Counter Not Retrievable by ICC Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification Terminal supports GET DATA for PIN Try Counter LT does not return PIN Try Counter in response to GET DATA (PIN Try Counter) CVM List is 'Plaintext PIN, always' Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display the Enter PIN message after having received the response to GET DATA command.
Page 515
2CM.014.00 GET DATA Not Supported by ICC

Test No. 2CM.014.00 Objective: To ensure that the terminal prompts for PIN entry if PIN Try Counter is not retrievable or GET DATA is not supported by LT. Reference: 2RM.012.0 - Book 4 Section 2.3.4.1 - GET DATA Not Supported by ICC Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification Terminal supports GET DATA for PTC LT returns status different from 90 00 to GET DATA (PIN Try Counter) CVM List is 'Plaintext PIN, always' Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display the Enter PIN message after having received the GET DATA command.
Page 516
2CM.015.00 Terminal Behaviour When PIN Try Counter Equals 0

Test No. 2CM.015.00 Objective: To ensure that the terminal sets the PIN Try Limit exceeded in the TVR to 1b, and continue the processing of CVM, if PIN Try counter returned by GET DATA is 0 Reference: 2RM.013.0 - Book 4 Section 2.3.4.1 - Terminal Behavior When PIN Try Counter Equals 0 Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification LT returns PIN Try Counter = 0 to GET DATA Terminal supports GET DATA for PIN Try Counter CVM List is 'Plaintext PIN, always' followed by 'Fail CVM , always' CDOL1 requests TSI, TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall not display any specific message regarding the PIN Try counter. TVR byte 3, bit 6 = 1 ie PIN Try Limit exceeded TVR byte 3, bit 8 = 1 ie Cardholder verification was failed TSI byte 1 , bit 7 = '1' ie Cardholder verification was performed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 517
2CM.016.00 Terminal Prompt for PIN Entry (PIN Try Counter >0)
Test No. 2CM.016.00 Objective: To ensure that the terminal prompts for PIN entry and displays a message such as Enter PIN, if PIN Try counter returned by GET DATA is not 0 Reference: 2RM.014.0 - Book 4 Section 2.3.4.1 - Terminal Prompt for PIN Entry (PIN Try Counter >0) Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification LT returns PIN Try Counter > 0 to GET DATA Terminal supports GET DATA for PIN Try Counter CVM List is Plaintext PIN always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display the Enter PIN message after having received the GET DATA command
Page 518
2CM.017.00 CVM is Set When Offline PIN is Successful

Test No. 2CM.017.00 Objective: To ensure that the terminal sets byte 3 of the CVM Result to successful, if offline PIN verification by the ICC is successful Reference: 2RM.015.0 - Book 4 Section 2.3.4.1 - CVM is Set When Offline PIN is Successful Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification LT returns PIN Try Counter > 0 to GET DATA if Terminal supports GET DATA for PTC or VERIFY (9000) CVM List is Plaintext PIN always LT returns 90 00 to VERIFY CDOL1 requests CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results Byte 3 = '02' (last CVM is successful)
Page 519
2CM.018.00 Offline PIN Not Successful

Test No. 2CM.018.00 Objective: To ensure that the terminal does not set CVM Result and continue the processing of CVM List, if offline PIN verification by the ICC is not successful Reference: 2RM.016.0 - Book 4 Section 2.3.4.1 - Offline PIN Not Successful Conditions: LT and Terminal support Cardholder verification Terminal supports Offline PIN verification LT returns PIN Try Counter > 0 to GET DATA if Terminal supports GET DATA for PTC or VERIFY (63 Cx, x = 0) CVM List is 'Plaintext PIN, always' followed by 'Fail CVM , always' LT returns status different from 90 00 to VERIFY CDOL1 requests TSI, TVR and CVM Results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 1 ie Cardholder verification was failed TSI byte 1 , bit 7 = '1' ie Cardholder verification was performed CVM Results show 'Fail CVM, always, process is failed' as the last CVM processed ('00 00 01')
Page 520
2CM.019.00 Online PIN used for CVM

Test No. 2CM.019.00 Objective: To ensure that the PIN Pad enciphers the PIN upon entry for transmission in the authorization or financial transaction, if CVM is online PIN verification Reference: 2RM.017.0 - Book 4 Section 2.3.4.2 - Online PIN used for CVM Conditions: LT and Terminal support Cardholder verification Terminal supports Enciphered PIN verified Online CVM List is Enciphered PIN verified Online always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization or financial request message shall contain encrypted PIN
Page 521
2CM.020.00 Online PIN When PIN Try Limit is Exceeded and Terminal Supports GET DATA for PIN Try Counter
Test No. 2CM.020.00 Objective: To ensure that the terminal allows a PIN to be entered for online verification even if the cards PIN Try Limit is exceeded Reference: 2RM.018.0 - Book 4 Section 2.3.4.2 - Online PIN When PIN Try Limit is Exceeded Conditions: Terminal supports Offline PIN (Plaintext or Enciphered) Terminal supports GET DATA for PIN Try Counter LT and Terminal support Cardholder verification Terminal supports Enciphered PIN verified Online CVM List requests Plaintext PIN if terminal supports followed by Enciphered Offline PIN if terminal supports followed by Online Enciphered PIN always. The first two CVRs (Plaintext PIN and Enciphered Offline PIN) shall have Byte 1, bit 7 of the CVM Code set to 1 (Applying succeeding CVR if this CVM is unsuccessful) LT returns PIN Try Counter = 0 to GET DATA CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 Cardholder verification was successful TVR byte 3, bit 6 = 1 PIN Try Limit exceeded TVR byte 3, bit 3 = 1 Online PIN entered Terminal shall display an Enter PIN Message Authorization or financial request message shall contain encrypted PIN
Page 522
2CM.020.01 Online PIN When PIN Try Limit is Exceeded and the Terminal does not support GET DATA for PIN Try Counter
Test No. 2CM.020.01 Objective: To ensure that the terminal allows a PIN to be entered for online verification even if the cards PIN Try Limit is exceeded Reference: 2RM.018.0 - Book 4 Section 2.3.4.2 - Online PIN When PIN Try Limit is Exceeded Conditions: Terminal supports Offline PIN (Plaintext or Enciphered) Terminal does not support GET DATA for PIN Try Counter LT and Terminal support Cardholder verification Terminal supports Enciphered PIN verified Online CVM List requests Plaintext PIN if terminal supports followed by Enciphered Offline PIN if terminal supports followed by Online Enciphered PIN always. The first two CVRs (Plaintext PIN and Enciphered Offline PIN) shall have Byte 1, bit 7 of the CVM Code set to 1 (Applying succeeding CVR if this CVM is unsuccessful) LT returns 63C0 to VERIFY command CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 Cardholder verification was successful TVR byte 3, bit 6 = 1 PIN Try Limit exceeded TVR byte 3, bit 3 = 1 Online PIN entered Terminal shall display an Enter PIN Message Terminal shall indicate incorrect PIN and request Enter PIN for Online Pin entry Authorization or financial request message shall contain encrypted PIN
Page 523
2CM.021.00 CVM Results Set for Online PIN

Test No. 2CM.021.00 Objective: To ensure that the terminal sets the CVM Results byte 3 to unknown when PIN is entered for online verification Reference: 2RM.019.0 - Book 4 Section 2.3.4.2 - CVM Results Set for Online PIN Conditions: LT and Terminal support Cardholder verification Terminal supports Enciphered PIN verified Online CVM is Enciphered PIN verified Online always CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 3 shall be unknown
Page 524
2CM.022.00 TVR is Set When PIN Entry is bypassed at Attended Terminal

Test No. 2CM.022.00 Objective: To ensure that the terminal sets the PIN entry required, PIN pad present, but PIN was not entered bit in the TVR to 1b and the PIN Try Limit exceeded bit in the TVR is not set to 1b, if an attended terminal bypasses PIN entry Reference: 2RM.020.0 - Book 4 Section 2.3.4.3 - TVR is Set When PIN Entry is bypassed at Attended Terminal Conditions: LT and Terminal support Cardholder verification Terminal supports PIN verification CVM List is * Plaintext PIN verification by ICC always * or Enciphered PIN verification performed by ICC always * or Enciphered PIN verification performed by ICC and signature always * or Enciphered PIN online always Terminal has PIN bypass capabilities Merchant forces the bypass of the PIN CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 4 = 1 ie PIN entry required, PIN pad present, but PIN was not entered TVR byte 3, bit 6 = 0 ie PIN Try Limit not exceeded
Page 525
2CM.023.00 CVM unsuccessful When PIN Entry is bypassed at Attended Terminal

Test No. 2CM.023.00 Objective: To ensure that the terminal considers the CVM as unsuccessful and continue the processing of CVM, if PIN entry is bypassed Reference: 2RM.021.0 - Book 4 Section 2.3.4.3 - CVM unsuccessful When PIN Entry is bypassed at Attended Terminal Conditions: LT and Terminal support Cardholder verification Terminal supports PIN verification Terminal has PIN bypass capabilities Merchant forces the bypass of the PIN The CVM List is such as: First CVM is: * Plaintext PIN verification by ICC always * or Enciphered PIN verification performed by ICC always * or Enciphered PIN verification performed by ICC and signature always * or Enciphered PIN online always (with bit 7 of CVM code set to Apply succeeding CVR is this CVM is unsuccessful) followed by another Cardholder Verification Rules (e.g. "No CVM required, always; signature, always) supported by the terminal in order to success the cardholder verification CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall not display any specific message regarding the PIN Try counter.
Page 526
EMVCo Type Approval - Terminal Level 2 - Test Cases TVR byte 3, bit 8 = 0 ie Cardholder verification was successful TSI byte 1 , bit 7 = 1 ie Cardholder verification was performed TVR byte 3, bit 4 =1 ie Pin Entry required and PIN Pad present, but PIN was not entered.
2CM.024.00 CVM is Set to unknown When Signature is Used

Test No. 2CM.024.00 Objective: To ensure that the terminal sets the CVM Results byte 3 to unknown when signature is the applicable CVM Reference: 2RM.022.0 - Book 4 Section 2.3.4.4 - CVM is Set to unknown When Signature is Used Conditions: LT and Terminal support Cardholder verification Terminal supports Signature CVM is Signature always CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 3 shall be unknown
Page 527
2CM.025.00 Terminal Prints Receipt With Line for Cardholder Signature

Test No. 2CM.025.00 Objective: To ensure that the terminal prints a receipt with line for Cardholder signature when signature is the applicable CVM Reference: 2RM.023.0 - Book 4 Section 2.3.4.4 - Terminal Prints Receipt With Line for Cardholder Signature Conditions: LT and Terminal support Cardholder verification Terminal supports Signature CVM is Signature always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall print a receipt with a line for Cardholder signature
Page 528
2CM.026.00 CVM is Set When no CVM is Required

Test No. 2CM.026.00 Objective: To ensure that the terminal sets the CVM Results byte 3 to successful when applicable CVM is 'No CVM Required' Reference: 2RM.024.0 - Book 4 Section 2.3.4.5 - CVM is Set When no CVM is Required Conditions: LT and Terminal support Cardholder verification Terminal supports 'No CVM required' CVM is 'No CVM required, always' CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 3 shall be successful
2CM.027.00 CVM is Set When CVM is Fail CVM Processing

Test No. 2CM.027.00 Objective: To ensure that the terminal sets the CVM Results byte 3 to Failed when applicable CVM is Fail CVM Reference: 2RM.025.0 - Book 4 Section 2.3.4.5 - CVM is Set When CVM is Fail CVM Processing Conditions: LT and Terminal support Cardholder verification CVM is 'Fail CVM, always' CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 3 shall be failed
Page 529
2CM.028.00 CVM Results Set With Method Code and Condition Code of Last CVM Performed
Test No. 2CM.028.00 Objective: To ensure that the terminal sets the CVM Results bytes 1 and 2 according to the last CVM performed Reference: 2RM.026.0 - Book 4 Section 2.3.4.5 - CVM Results Set With Method Code and Condition Code of Last CVM Performed Conditions: test is made with at least two CVM lists and behaviour, for instance: * Offline PIN always followed by Signature always and PIN is presented OK * Offline PIN always followed by Signature always and PIN not presented OK * Signature if supported CVM CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 1 and 2 shall always be set in accordance with last CVM performed in the list. for the example above content is: * Offline PIN always * Signature always * Signature if supported CVM
Page 530
2CM.029.00 CVM Results Set When Last CVM Not Considered Successful
Test No. 2CM.029.00 Objective: To ensure that the terminal sets the CVM Results byte 3 to failed when the last CVM performed was not considered as successful Reference: 2RM.027.0 - Book 4 Section 2.3.4.5 - CVM Results Set When Last CVM Not Considered Successful Conditions: LT and Terminal support Cardholder verification Test is made with at least two CVM lists and behavior, for instance: * Offline PIN always and PIN not presented OK * CVM is 'Fail CVM, always' * Signature always and terminal does not support signature CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 3 shall be failed
Page 531
2CM.030.00 CVM Results Set When No CVM Was Performed

Test No. 2CM.030.00 Objective: To ensure that the terminal sets the CVM Results byte 1 to No CVM performed if no CVM is present or there is no CVM conditions satisfied Reference: 2RM.028.0 - Book 4 Section 2.3.4.5 - CVM Results Set When No CVM Was Performed Conditions: LT and Terminal support Cardholder verification Test 1: no CVM list Test 2: CVM list but no satisfied conditions for instance Offline PIN if supported followed by signature if Amount under X and Terminal does not support PIN and Amount is over X CDOL1 requests CVM results Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion CVM Results byte 1 shall be no CVM performed
Page 532
2CM.031.00 Terminal Checks Presence of Application Selected

Test No. 2CM.031.00 Objective: To ensure that if the terminal has an exception file, the terminal checks the presence of the application selected in the exception file and does not set the Card appears in Exception file bit in the TVR to 1b, if no match is found with the current PAN Reference: 2RM.029.0 - Book 4 Section 2.3.5 - Terminal Checks Presence of Application Selected Conditions: Terminal supports exception file Exception File does not contain the PAN of LT CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 5 = 0 ie Card does not appear in Exception file
Page 533
2CM.032.00 TVR Set if Match is Found in Exception File

Test No. 2CM.032.00 Objective: To ensure that the terminal sets the Card appears in Exception file bit in the TVR to 1b, if Terminal has an exception file and a match is found with the current PAN Reference: 2RM.030.0 - Book 4 Section 2.3.5 - TVR Set if Match is Found in Exception File Conditions: Terminal supports exception file Exception File contains the PAN of LT
CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 1, bit 5 = 1 ie Card appears in Exception file
Page 534
2CM.033.00 Authorization Response Code Set When Terminal Accepts Transaction Offline
Test No. 2CM.033.00 Objective: To ensure that the terminal sets Authorization Response Code to Offline approved if result of Terminal Action Analysis is Offline Reference: 2RM.031.0 - Book 4 Section 2.3.6 - Authorization Response Code Set When Terminal Accepts Transaction Offline Conditions: IAC and TAC are set so that Transaction is approved Offline CDOL1 requests Authorization Response Code
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be Offline Approved whatever response of ICC
2CM.034.00 Authorization Response Code Set When Terminal Declines Transaction Offline
Test No. 2CM.034.00 Objective: To ensure that the terminal sets Authorization Response Code to Declined Offline if result of Terminal Action Analysis is to decline offline Reference: 2RM.032.0 - Book 4 Section 2.3.6 - Authorization Response Code Set When Terminal Declines Transaction Offline Conditions: IAC and TAC are set so that Transaction is declined offline CDOL1 requests Authorization Response Code
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be Declined Offline
Page 535
2CM.035.00 Authorization Response Code Not Set When Terminal Opts To Transmit Transaction Online
Test No. 2CM.035.00 Objective: To ensure that the terminal does not set Authorization Response Code to any value if result of Terminal Action Analysis is to transmit online Reference: 2RM.033.0 - Book 4 Section 2.3.6 - Authorization Response Code Not Set When Terminal Opts To Transmit Transaction Online Conditions: IAC and TAC are set so that Transaction is transmit online CDOL1 requests Authorization Response Code Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall not be filled
2CM.036.00 Terminal Completes Transaction When Card Indicated Approval

Test No. 2CM.036.00 Objective: To ensure that the terminal completes the transaction if the card returned an Approval to GENERATE AC Reference: 2RM.034.0 - Book 4 Section 2.3.7 - Terminal Completes Transaction When Card Indicated Approval Conditions: LT returns TC to GENERATE AC (Test made with TC at first GENERATE AC and at second GENERATE AC) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion
Page 536
2CM.037.00 Terminal Declines Transaction When Card Indicated Denial

Test No. 2CM.037.00 Objective: To ensure that the terminal declines the transaction if the card returned a Decline to GENERATE AC Reference: 2RM.035.0 - Book 4 Section 2.3.7 - Terminal Declines Transaction When Card Indicated Denial Conditions: LT returns AAC to GENERATE AC (Test made with AAC at first GENERATE AC and at second GENERATE AC) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion
2CM.038.00 Terminal Transmits Auth. or Financial Transaction Request Message

Test No. 2CM.038.00 Objective: To ensure that the terminal transmits a financial or authorization Request message if the card indicates to process Online in response to GENERATE AC Reference: 2RM.036.0 - Book 4 Section 2.3.7 - Terminal Transmits Auth. or Financial Transaction Request Message Conditions: LT returns ARQC to GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall format and transmit a financial or authorization message
Page 537
2CM.039.00 Terminal Performs Referrals if Card Indicates a Referral

Test No. 2CM.039.00 Objective: To ensure that the terminal performs a referral if the card indicates a referral in response to GENERATE AC Reference: 2RM.037.0 - Book 4 Section 2.3.7 - Terminal Performs Referrals if Card Indicates a Referral Conditions: LT returns AAR to GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall display a Call Your Bank message
2CM.040.00 Advice is Requested by Card and is Supported by the Terminal and transaction is captured
Test No. 2CM.040.00 Objective: To ensure that the terminal does not create an advice if the card requests it but the transaction is captured Reference: 2RM.038.0 - Book 4 Section 2.3.7 - Advice is Requested by Card and is Supported by the Terminal and transaction is captured Conditions: LT returns Advice required in first GENERATE AC Terminal acquirer interface protocol Supports Advices Transaction is captured (batch or online data capture) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall not transmit an advice message
Page 538
2CM.041.00 Advice is Requested by Card and is Supported by the Terminal and transaction is not captured
Test No. 2CM.041.00 Objective: To ensure that the terminal creates an advice if the card requests it and the transaction is not captured Reference: 2RM.039.0 - Book 4 Section 2.3.7 - Advice is Requested by Card and is Supported by the Terminal and transaction is not captured Conditions: LT returns Advice required in first GENERATE AC Terminal Supports acquirer interface protocol Advices Transaction is not captured (LT returns declined) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall either prepare an offline advice message or transmit an online advice message
2CM.042.00 Terminal Terminates Transaction if Card Indicates Service Not Allowed

Test No. 2CM.042.00 Objective: To ensure that the terminal displays a Not accepted message and terminates the transaction if the card indicates a Service not allowed in response to GENERATE AC Reference: 2RM.040.0 - Book 4 Section 2.3.7 - Terminal Terminates Transaction if Card Indicates Service Not Allowed Conditions: LT returns Service not allowed in first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall terminate the transaction The Terminal should display a Not accepted message
Page 539
2CM.042.06 Combined DDA/AC Generation failed and ICC returned an ARQC

Test No. 2CM.042.06 Objective: To ensure that if Combined DDA/AC Generation failed and if the card returns an ARQC, the terminal sets the 'Combined DDA/AC Generation failed' bit in the TVR to 1b and completes the transaction by performing immediately a second Generate AC requesting for an AAC. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC Enhanced Combined DDA/AC signature generated in LT is failed LT returns an ARQC in first Generate AC CDOL2 requests TVR and TSI
Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC Authentication). Pass Criteria: The terminal shall process the transaction until completion The terminal shall immediately perform a second Generate AC The terminal shall request for an AAC to the second Generate AC TVR byte 1, bit 3 = 1 i.e. Combined DDA/AC Generation failed TSI byte 1, bit 8 = 1 i.e. Offline Data Authentication was performed The terminal shall decline the transaction
Page 540
2CM.043.00 Terminal Decides To Accept or Decline Transaction and Issues 2nd GENERATE AC
Test No. 2CM.043.00 Objective: To ensure that the terminal issue a second GENERATE AC indicating the content of the Authorization Response Code, if transaction is processed online Reference: 2RM.041.0 - Book 4 Section 2.3.8 - Terminal Decides To Accept or Decline nd Transaction and Issues 2 GEN AC Conditions: Transaction is processed online Test 1: Issuer returns an Authorization Response Code indicating acceptance Test 2: Issuer returns an Authorization Response Code indicating decline Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC indicating TC for test 1 and AAC for test 2
Page 541
2CM.044.00 Authorization Response Code is Online Approved

Test No. 2CM.044.00 Objective: To ensure that the terminal transmit a reversal message, if transaction is processed online and transaction is captured online and Authorization Response Code is online approved and card returns AAC to second GENERATE AC Reference: 2RM.042.0 - Book 4 Section 2.3.8 - Authorization Response Code is Online Approved Conditions: Transaction is processed online Transactions are captured online (financial message) Authorization Response Code returned is online approved LT returns AAC to second GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall format and transmit a Reversal Message
Page 542
2CM.045.00 Terminal Support of Issuer Scripts in Authorization or Financial Transaction Response

Test No. 2CM.045.00 Objective: To ensure that the terminal is able to manage and perform scripts if it receives one or several scripts with the total length is less than or equal to 128 bytes in authorization or financial response Reference: 2RM.043.0 - Book 4 Section 2.3.9 - Terminal Support of Issuer Scripts in Authorization or Financial Transaction Response Conditions: Transaction is processed online Response contains one or several scripts with total length is 128 bytes Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive APDU commands according to the scripts sent in the response
2CM.048.00 Terminal Reporting of Script Identifier

Test No. 2CM.048.00 Objective: To ensure that the terminal reports in the Issuer Script Results the results of scripts processed Reference: 2RM.047.0 - Book 4 Section 2.3.9 - Terminal Reporting of Script Identifier Conditions: Transaction is processed online Response contains one or several scripts with Tag 71 or 72 (tests can be made with scripts that fail or succeed) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Issuer Script Results (contained in Financial Confirmation message or Batch Data Captured message) shall match result of scripts sent to the card (in particular scripts order, script Identifier, failure or success)
Page 543
2CM.049.00 Issuer Script Results Set When Error Code Was Returned by Card
Test No. 2CM.049.00 Objective: To ensure that the terminal reports a script error in the Issuer Script Results. Reference: 2RM.048.0 - Book 4 Section 2.3.9 - Issuer Script Results Set When Error Code Was Returned by Card Conditions: Transaction is processed online Response contains one script LT returns an error to one of the command of the script (test can be made with several sequence number for the command that fails) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Issuer Script Results (contained in Financial Confirmation message or Batch Data Captured message) shall have first nibble of byte one set to Script Processing failed and the second nibble shall contain the sequence number of the command that failed)
Page 544
2CM.050.00 Issuer Script Results Set When No Error Code Was Returned by Card
Test No. 2CM.050.00 Objective: To ensure that the terminal reports a script success in the Issuer Script Results. Reference: 2RM.049.0 - Book 4 Section 2.3.9 - Issuer Script Results Set When No Error Code Was Returned by Card Conditions: Transaction is processed online Response contains one script LT returns 90 00 to all command of the script Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Issuer Script Results (contained in Financial Confirmation message or Batch Data Captured message) shall have first nibble of byte one set to Script Processing successful and the second nibble set to 0
Page 545
2CM.051.00 Terminal Transmission of Issuer Script Results

Test No. 2CM.051.00 Objective: To ensure that the terminal transmits the Issuer Script Result in Batch Data capture Message or Financial Confirmation Message or Reversal Message Reference: 2RM.050.0 - Book 4 Section 2.3.9 - Terminal Transmission of Issuer Script Results Conditions: Transaction is processed online Response contains one or several scripts Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall include Issuer Script Result in one of the following message (Batch Data capture Message or Financial Confirmation Message or Reversal Message)
Page 546
2CM.052.00 Terminal Creates an Advice When No Message is Created for Transaction

Test No. 2CM.052.00 Objective: To ensure that the terminal creates an Advice message containing the Issuer Script Results if no message is created for the transaction (declined transaction) Reference: 2RM.051.0 - Book 4 Section 2.3.9 - Terminal Creates an Advice When No Message is Created for Transaction Conditions: Terminal supports Advices Transaction is processed online Final GENERATE AC returns AAC Response contains one or several scripts Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall create an Advice Message including Issuer Script Results
Page 547
2CM.055.00 Terminal Supporting DDA Shall Support SDA

Test No. 2CM.055.00 Objective: To ensure that the terminal supports Static Data Authentication if it supports Dynamic Data Authentication Reference: 2RM.054.0 - Book 4 Section 2.4 - Terminal Supporting DDA Shall Support SDA Conditions: LT supports SDA Terminal capabilities indicates DDA support Signed Static Data is good in LT Terminal contains the CA Public Key referenced in LT CDOL1 requests Terminal Capabilities, TSI, and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal Capabilities shall indicate Static Data Authentication support TVR byte 3, bit 7 = 0 ie Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 548
2CM.056.00 Offline Only Terminal Shall Support SDA

Test No. 2CM.056.00 Objective: To ensure that the terminal supports Static Data Authentication if it is offline only Reference: 2RM.055.0 - Book 4 Section 2.4 - Offline Only Terminal Shall Support SDA Conditions: LT supports SDA Terminal is offline only Signed Static Data is good in LT Terminal contains the CA Public Key referenced in LT CDOL1 requests Terminal Capabilities, TSI, and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal Capabilities shall indicate Static Data Authentication support TVR byte 3, bit 7 = 0 ie Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 549
2CM.057.00 Offline Terminal With Online Capability Shall Support SDA

Test No. 2CM.057.00 Objective: To ensure that the terminal supports Static Data Authentication if it is offline with online capabilities Reference: 2RM.056.0 - Book 4 Section 2.4 - Offline Terminal With Online Capability Shall Support SDA Conditions: LT supports SDA Terminal is offline with online capabilities Signed Static Data is good in LT Terminal contains the CA Public Key referenced in LT CDOL1 requests Terminal Capabilities, TSI, and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal Capabilities shall indicate Static Data Authentication support TVR byte 3, bit 7 = 0 ie Static Data Authentication succeeded TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed
Page 550
2CM.058.00 Offline Only Terminal Shall Support Terminal Risk Management

Test No. 2CM.058.00 Objective: To ensure that the terminal supports Terminal Risk Management if it is offline only Reference: 2RM.057.0 - Book 4 Section 2.4 - Offline Only Terminal Shall Support Terminal Risk Management Conditions: Terminal is Offline only LT supports Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 551
2CM.059.00 Offline Terminal With Online Capability Shall Support Terminal Risk Management
Test No. 2CM.059.00 Objective: To ensure that the terminal supports Terminal Risk Management if it is offline with online capabilities Reference: 2RM.058.0 - Book 4 Section 2.4 - Offline Terminal With Online Capability Shall Support Terminal Risk Management Conditions: Terminal is Offline with online capabilities LT supports Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 552
2CM.060.00 Financial Institution Terminal Supports TRM

Test No. 2CM.060.00 Objective: To ensure that the terminal supports Terminal Risk Management if it is a Financial institution Terminal Reference: 2RM.059.0 - Book 4 Section 2.4 - Financial Institution Terminal Supports TRM Conditions: Terminal is Financial institution Terminal (type 1x) LT supports Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI and TVR and Terminal Type Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 553
2CM.061.00 Merchant Controlled Terminal Supports TRM

Test No. 2CM.061.00 Objective: To ensure that the terminal supports Terminal Risk Management if it is a Merchant Controlled Terminal Reference: 2RM.060.0 - Book 4 Section 2.4 - Merchant Controlled Terminal Supports TRM Conditions: Terminal is Merchant Controlled Terminal (type 2x) LT supports Terminal Risk Management Transaction Amount is above Terminal floor Limit Lower and Upper Consecutive Offline Limits are present in the LT ATC is not returned by GET DATA CDOL1 requests TSI and TVR and Terminal Type Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 8 = 1 ie Transaction exceeds floor limit TVR byte 4, bit 7 = 1 ie Lower Consecutive Offline Limit exceeded TVR byte 4, bit 6 = 1 ie Upper Consecutive Offline Limit exceeded TSI byte 1, bit 4 = 1 ie Terminal Risk Management was performed
Page 554
2CM.062.00 Terminal Displays Amount of Transaction

Test No. 2CM.062.00 Objective: To ensure that the terminal indicates the amount of the transaction to the cardholder Reference: 2RM.061.0 - Book 4 Section 2.5.1 - Terminal Displays Amount of Transaction Conditions: No specific conditions
Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall indicate the Amount of transaction or print it on a receipt to the cardholder
2CM.063.00 Cashback Amount is Transmitted in the Amount, Other Data Object

Test No. 2CM.063.00 Objective: To ensure that the terminal uses Amount Other field for Cash Back Amount, if cash back is supported Reference: 2RM.062.0 - Book 4 Section 2.5.1 - Cashback Amount is Transmitted in the Amount, Other Data Object Conditions: Terminal supports Cash Back AUC in LT indicate cashback supported CDOL1 requests Amount Other (in Numeric or Binary format) Cardholder asks for Cash back Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Amount Other shall contain value entered for Cashback
Page 555
2CM.064.00 Purchase and Cashback Transmitted in Amount Authorised

Test No. 2CM.064.00 Objective: To ensure that the terminal include Purchase Amount and Cashback Amount in Amount Authorized Reference: 2RM.063.0 - Book 4 Section 2.5.1 - Purchase and Cashback Transmitted in Amount Authorised Conditions: Terminal supports Cash Back AUC in LT indicate cashback supported CDOL1 requests Amount Authorized (in Numeric or Binary format), and Amount Other (in Numeric or Binary format) Cardholder asks for Cash back Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Amount Authorized shall be the sum of Cashback Amount and Purchase Amount
Page 556
2CM.066.00 Authorised Amount Is Expressed With Implicit Decimal Point

Test No. 2CM.066.00 Objective: To ensure that the terminal stores Amount Authorized with Implicit Decimal Point Reference: 2RM.065.0 - Book 4 Section 2.5.1 - Authorized Amount Is Expressed With Implicit Decimal Point Conditions: Purchase Amount has decimal values CDOL1 requests Amount Authorized Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Amount Authorized shall be expressed with implicit decimal point for the currency used
Page 557
2CM.067.00 Other Amount Is Expressed With Implicit Decimal Point

Test No. 2CM.067.00 Objective: To ensure that the terminal stores Amount Other with Implicit Decimal Point Reference: 2RM.066.0 - Book 4 Section 2.5.1 - Other Amount Is Expressed With Implicit Decimal Point Conditions: Purchase Amount has decimal values Terminal supports Cash Back AUC in LT indicate cashback supported Cardholder asks for Cash back CDOL1 requests Amount Other Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Amount Other shall be expressed with implicit decimal point for the currency used
Page 558
2CM.068.00 Attended Terminal Displays Message When Card Requests Voice Referral
Test No. 2CM.068.00 Objective: To ensure that an attended terminal displays the Call Your Bank message, if the card requests a Referral in the response to first GENERATE AC Reference: 2RM.067.0 - Book 4 Section 2.5.2.1 - Attended Terminal Displays Message When Card Requests Voice Referral Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display the Call your Bank message
2CM.069.00 Application Data Displayed or Printed To Perform Referral initiated by card

Test No. 2CM.069.00 Objective: To ensure that an attended terminal displays or prints appropriate application data like the PAN, if the card requests a Referral in the response to first GENERATE AC Reference: 2RM.068.0 - Book 4 Section 2.5.2.1 - Application Data Displayed or Printed To Perform Referral initiated by card Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display or print PAN and other appropriate data
Page 559
2CM.070.00 Messages Displayed For Attendant to Indicate Approval or Denial of a Referral initiated by card
Test No. 2CM.070.00 Objective: To ensure that an attended terminal displays a message requesting the attendant to enter the response from the Bank, if the card requests a Referral in the response to first GENERATE AC Reference: 2RM.069.0 - Book 4 Section 2.5.2.1 - Messages Displayed For Attendant to Indicate Approval or Denial of a Referral initiated by card Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display a message requesting the attendant to enter the response from the Bank (after Call your Bank and data messages)
Page 560
2CM.071.00 Authorization Response Code Set as a Result of Referral Process initiated by card
Test No. 2CM.071.00 Objective: To ensure that an attended terminal sets the Authorization Response Code in accordance with response from the Bank entered if the card requests a Referral in the response to first GENERATE AC Reference: 2RM.070.0 - Book 4 Section 2.5.2.1 - Authorization Response Code Set as a Result of Referral Process initiated by card Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC CDOL2 requests Authorization Response Code Test 1: transaction approved by the Bank Test 2: transaction declined by the Bank Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be Approved for test 1 and declined for test 2
Page 561
2CM.072.00 Terminal Issues Second GENERATE AC command as a Result of Referral Process initiated by card
Test No. 2CM.072.00 Objective: To ensure that if the card requests a Referral in the response to first GENERATE AC, an attended terminal does not send EXTERNAL AUTHENTICATE command and sends a second GENERATE AC command in accordance with response from the Bank entered Reference: 2RM.071.0 - Book 4 Section 2.5.2.1 - Terminal Issues Second GENERATE AC command as a Result of Referral Process initiated by card Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC Test 1: transaction approved by the Bank Test 2: transaction declined by the Bank Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT shall not receive an EXTERNAL AUTHENTICATE command LT shall receive a second GENERATE AC command requesting a TC for test 1 and an AAC for test 2
Page 562
2CM.073.00 Terminal Behaviour When Transaction is Forced Online

Test No. 2CM.073.00 Objective: To ensure that if the card requests a Referral in the response to first GENERATE AC and if the transaction is forced online, an attended terminal does not set the Authorization Response Code and transmits an Authorization or Financial Request Message using the AAR as an ARQC Reference: 2RM.072.0 - Book 4 Section 2.5.2.1 - Terminal Behavior When Transaction is Forced Online Conditions: Terminal is an attended terminal LT returns a Referral (AAR) in response to first GENERATE AC CDOL2 requests Authorization Response Code Transaction is forced online Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be filled according to the response from the Issuer simulator The terminal shall transmit an Authorization or Financial Request Message containing the AAR instead of ARQC
Page 563
2CM.074.00 Terminal Displays Message To Attendant When Issuer Requests Voice Referral
Test No. 2CM.074.00 Objective: To ensure that if the Authorization Response Code returned by the issuer, indicates a voice referral, an attended terminal displays the Call Your Bank message Reference: 2RM.073.0 - Book 4 Section 2.5.2.2 - Terminal Displays Message To Attendant When Issuer Requests Voice Referral Conditions: Terminal is an attended terminal Transaction is performed online (first GENERATE AC returns ARQC) Authorization Response Code returned in the response indicates a voice Referral Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display the Call your Bank message
Page 564
2CM.075.00 Data Displayed or Printed to Perform Referral initiated by issuer

Test No. 2CM.075.00 Objective: To ensure that if the Authorization Response Code returned by the issuer, indicates a voice referral, an attended terminal displays or prints appropriate application data like the PAN Reference: 2RM.074.0 - Book 4 Section 2.5.2.2 - Data Displayed or Printed to Perform Referral initiated by issuer Conditions: Terminal is an attended terminal Transaction is performed online (first GENERATE AC returns ARQC) Authorization Response Code returned in the response indicates a voice Referral Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display or print PAN and other appropriate data
Page 565
2CM.076.00 Messages Displayed Requesting Attendant to Indicate Approval or Denial of a Referral initiated by issuer
Test No. 2CM.076.00 Objective: To ensure that if the Authorization Response Code returned by the issuer, indicates a voice referral, an attended terminal displays a message requesting the attendant to enter the response from the Bank Reference: 2RM.075.0 - Book 4 Section 2.5.2.2 - Messages Displayed Requesting Attendant to Indicate Approval or Denial of a Referral initiated by issuer Conditions: Terminal is an attended terminal Transaction is performed online (first GENERATE AC returns ARQC) Authorization Response Code returned in the response indicates a voice Referral Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall display a message requesting the attendant to enter the response from the Bank (after Call your Bank and data messages)
Page 566
2CM.077.00 Authorization Response Code when Referral is initiated by Issuer

Test No. 2CM.077.00 Objective: To ensure that if the Authorization Response Code returned by the issuer, indicates a voice referral, an attended terminal does not modify the Authorization Response Code received Reference: 2RM.076.0 - Book 4 Section 2.5.2.2 - Authorization Response Code when Referral is initiated by Issuer Conditions: Terminal is an attended terminal Transaction is performed online (first GENERATE AC returns ARQC) Authorization Response Code returned in the response indicates a voice Referral CDOL2 requests Authorization Response Code Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be the same as the one received from issuer.
Page 567
2CM.078.00 Terminal Issues Second GENERATE AC

Test No. 2CM.078.00 Objective: To ensure that if the Authorization Response Code returned by the issuer, indicates a voice referral, an attended Terminal sends a second GENERATE AC command in accordance with response from the Bank entered manually Reference: 2RM.077.0 - Book 4 Section 2.5.2.2 - Terminal Issues Second GENERATE AC Conditions: Terminal is an attended terminal Transaction is performed online (first GENERATE AC returns ARQC) Authorization Response Code returned in the response indicates a voice Referral Test 1: transaction approved by the Bank Test 2: transaction declined by the Bank Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion LT may receive an EXTERNAL AUTHENTICATE command LT shall receive a second GENERATE AC command requesting a TC for test 1 and an AAC for test 2
Page 568
2CM.079.00 TVR Set When Merchant Forces Transaction Online

Test No. 2CM.079.00 Objective: To ensure that if a transaction is forced online, an attended Terminal sets the Merchant forced transaction online bit in the TVR to 1b Reference: 2RM.078.0 - Book 4 Section 2.5.3 - TVR Set When Merchant Forces Transaction Online Conditions: Terminal is an attended terminal Transaction is forced online CDOL2 requests TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 4, bit 4 = 1 ie Merchant forced transaction
2CM.080.00 Attendant forces Approval of the Transaction

Test No. 2CM.080.00 Objective: To ensure that if attendant forces the approval of a transaction, the terminal either sends online financial advice or creates a batch data capture entry Reference: 2RM.079.0 - Book 4 Section 2.5.4 - Attendant forces Approval of the Transaction Conditions: Terminal is an attended terminal Attendant forces acceptance of the transaction (test is made with several response from LT) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall either send online financial advice or create a batch data capture entry
Page 569
2CM.081.00 Authorization Response Code when acceptance is forced

Test No. 2CM.081.00 Objective: To ensure that if attendant forces the approval of a transaction, the terminal does not modify the Authorization Response Code Reference: 2RM.080.0 - Book 4 Section 2.5.4 - Authorization Response Code when acceptance is forced Conditions: Terminal is an attended terminal Transaction is performed online Attendant forces acceptance of the transaction Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code in online financial advice or in batch data capture entry shall be the same as the one received from Issuer
Page 570
2CM.082.00 Terminal Sets Indicator When Attendant forces Approval of the Transaction
Test No. 2CM.082.00 Objective: To ensure that the terminal sets an indicator in the online advice or batch data capture if the attendant forced acceptance of the transaction. Reference: 2RM.081.0 - Book 4 Section 2.5.4 - Terminal Sets Indicator When Attendant forces Approval of the Transaction Conditions: Terminal is an attended terminal Transaction is performed online Attendant forces acceptance of the transaction Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall set an indicator in the online advice or batch data capture that the attendant forced acceptance of the transaction
2CM.083.00 Terminal Maintains Transaction Sequence Counter

Test No. 2CM.083.00 Objective: To ensure that the terminal maintains a Transaction Sequence Counter Reference: 2RM.082.0 - Book 4 Section 2.5.5 - Terminal Maintains Transaction Sequence Counter Conditions: Several Transaction are performed CDOL1 requests Transaction Sequence Counter Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion for each transaction Transaction Sequence Counter shall be incremented by one at each transaction
Page 571
2CM.085.00 Generation of Unpredictable Number

Test No. 2CM.085.00 Objective: To ensure that the terminal is able to generate an unpredictable number Reference: 2RM.084.0 - Book 4 Section 2.5.6 - Generation of Unpredictable Number Conditions: Several Transaction are performed CDOL1 requests Unpredictable Number Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion for each transaction Unpredictable Number shall be different at each transaction
2CM.086.00 Terminal Reading of Service Code on Magnetic Stripe

Test No. 2CM.086.00 Objective: To ensure that the terminal displays a message Use Chip Reader if the magstripe is read and the Service Code begins with 2 or 6, and if the terminal does not have a combined IC and magnetic stripe reader. Reference: 2RM.085.0 - Book 4 Section 2.6 - Terminal Reading of Service Code on Magnetic Stripe (1) Conditions: Magstripe LT is read with Service Code beginning with 2 or 6 Procedure: Application in LT is selected and transaction is processed with LT (Magstripe shall be used) Pass Criteria: The terminal shall prompt the user to insert the ICC
Page 572
2CM.087.00 Terminal Reading of Service Code on Magnetic Stripe

Test No. 2CM.087.00 Objective: To ensure that the terminal switch to IC process if the magstripe is read and the Service Code begins with 2 or 6 Reference: 2RM.086.0 - Book 4 Section 2.6 - Terminal Reading of Service Code on Magnetic Stripe (2) Conditions: LT is a combined magstripe and Chip ICC Magstripe Service Code beginning with 2 or 6 Terminal starts by reading magstripe Procedure: Application in LT is selected and transaction is processed with LT (Magstripe shall be used) Pass Criteria: The terminal shall switch to IC process and shall send EMV command to LT
Page 573
2CM.091.00 POS Entry Mode Code Read

Test No. 2CM.091.00 Objective: To ensure that if the terminal fails to read the ICC but can read magstripe and Service code begins with 2 or 6, the terminal set POS entry mode code to Magnetic Stripe read, last transaction was an unsuccessful IC read in the transaction message Reference: 2RM.091.0 - Book 4 Section 2.6.2 - POS Entry Mode Code Read Conditions: LT has non functional ICC LT has a magstripe with Service Code beginning with 2 or 6 Terminal has magstripe and chip capabilities Procedure: Transaction is started with LT ICC Pass Criteria: The terminal shall switch to magstripe processing The transaction message (financial or batch data capture) shall have the POS entry mode code set to Magnetic Stripe read, last transaction was an unsuccessful IC read
Page 574
2CM.092.00 Calculation of Dates Associated With Data Authentication

Test No. 2CM.092.00 Objective: To ensure that the terminal is capable of properly calculate date associated with data authentication for dates before, including, and after the year 2000 Reference: 2RM.092.0 - Book 4 Section 2.7.1 - Calculation of Dates Associated With Data Authentication Conditions: Terminal and LT support Static Data Authentication CDOL1 requests TSI and TVR Issuer Public Key Certificate in LT is calculated with different Certificate Expiration Dates (several tests): * Certificate Expiration Dates before year 2000 * Certificate Expiration Dates in year 2000 * Certificate Expiration Dates after year 2000 Procedure: Application in LT is selected and transaction is processed with LT (in particular Static Data Authentication). Pass Criteria: The terminal shall process the transaction until completion. TSI byte 1, bit 8 = 1 ie Offline Data Authentication was performed TVR byte 1, bit 7 shall be set according to the Certificate Expiration Date (1 if before the current date, 0 if in or after the current date)
Page 575
2CM.093.00 Calculation of Dates Associated With Processing Restrictions

Test No. 2CM.093.00 Objective: To ensure that the terminal is capable of properly calculate date associated with processing restrictions for dates before, including, and after the year 2000 Reference: 2RM.093.0 - Book 4 Section 2.7.2 - Calculation of Dates Associated With Processing Restrictions Conditions: Application Effective Date is present in the LT with different values (several tests) * Application Effective Dates before year 2000 * Application Effective Dates in year 2000 * Application Effective Dates after year 2000 Application Expiration Date is present in the LT with different values (several tests) * Application Expiration Dates before year 2000 * Application Expiration Dates in year 2000 * Application Expiration Dates after year 2000 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 7 shall be set according to the Application Expiration Dates (1 if after the current date, 0 if before the current date) TVR byte 2, bit 6 shall be set according to the Application Effective Dates (0 if before the current date, 1 if after the current date)
Page 576
2CM.094.00 Calculation, Storage, and Display Date-Dependant Fields For Year 2000 +
Test No. 2CM.094.00 Objective: To ensure that the terminal is able to accurately calculate and store date dependent fields representing the year 2000 Reference: 2RM.094.0 - Book 4 Section 2.7.3 - Calculation, Storage, and Display DateDependant Fields For Year 2000 + Conditions: Internal Date in the terminal is set to different value (several tests) * 31/12/1999 23h 59min * 28/02/2000 23h 59min CDOL1 requests Transaction Date and Transaction Time Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. Transaction Date shall have been updated to correct value: * 01/01/2000 * 29/02/2000
Page 577
2CM.095.00 Processing the Year

Test No. 2CM.095.00 Objective: To ensure that the terminal is able process 2 digits year correctly Reference: 2RM.095.0 - Book 4 Section 2.7.3 - Processing the Year Conditions: Application Expiration Date is present in the LT with different values (several tests) * Application Expiration Dates with year between 00 and 49 * Application Expiration Dates with year between 50 and 99 CDOL1 requests TVR Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall process the transaction until completion. TVR byte 2, bit 7 shall be set according to the Application Expiration Dates (1 if before the current date, 0 if after the current date)
2CM.096.00 Colouring of Command Keys

Test No. 2CM.096.00 Objective: To ensure that the terminal has correct colors affected to command keys if these colors are used on the device Reference: 2RM.096.0 - Book 4 Section 3.1.1 - Coloring of Command Keys Conditions: No specific conditions
Procedure: Visual inspection by the tester is required Pass Criteria: Enter Key shall be green Cancel Key shall be red Clear Key shall be yellow
Page 578
2CM.099.00 Numeric and Command Keys on PIN Pad

Test No. 2CM.099.00 Objective: To ensure that if the terminal is equipped with a PIN Pad, it comprises the numeric and Enter and Cancel command keys Reference: 2RM.099.0 - Book 4 Section 3.1.2 - Numeric and Command Keys on PIN Pad Conditions: Terminal is equipped with a PIN Pad Procedure: Visual inspection by the tester is required Pass Criteria: PIN Pad shall comprise the numeric and Enter and Cancel command keys
2CM.100.00 Numeric Layout of PIN Pad

Test No. 2CM.100.00 Objective: To ensure that if the terminal is equipped with a PIN Pad, the numeric layout of the PIN pad complies with ISO 9564, except for cardholdercontrolled terminals Reference: 2RM.100.0 - Book 4 Section 3.1.2 - Numeric Layout of PIN Pad Conditions: Terminal is equipped with a PIN Pad Terminal is not cardholder-controlled terminal Procedure: Visual inspection by the tester is required Pass Criteria: PIN Pad numeric layout shall comply with ISO 9564
Page 579
2CM.102.00 Display For Attendant for Attended Terminal

Test No. 2CM.102.00 Objective: To ensure that if the terminal is attended, it has a display for the attendant Reference: 2RM.102.0 - Book 4 Section 3.2 - Display For Attendant for Attended Terminal Conditions: Terminal is attended terminal Procedure: Visual inspection by the tester is required Pass Criteria: Terminal shall have a display for the attendant
2CM.103.00 Display of Alphanumeric Characters

Test No. 2CM.103.00 Objective: To ensure that if the terminal has a display, it is capable of displaying at least 32 alphanumeric characters (two lines of 16 positions each). Reference: 2RM.103.0 - Book 4 Section 3.2 - Display of Alphanumeric Characters Conditions: Terminal has a display Procedure: Visual inspection by the tester is required Pass Criteria: Display shall be capable of displaying at least 32 alphanumeric characters (two lines of 16 positions each).
Page 580
2CM.104.00 Protection of Software and Data

Test No. 2CM.104.00 Objective: To ensure that software as well as data initialized in the terminal or any part of the terminal, including cryptographic keys, are not erased or altered for the period of time the software and data are valid. Reference: 2RM.104.0 - Book 4 Section 3.3 - Protection of Software and Data Conditions: No specific conditions Procedure: Visual inspection by the tester is required in the terminal data bases Pass Criteria: Terminal software, data initialized and cryptographic keys shall not be erased or altered for the period of time the software and data are valid Data shall be available during all the time of the test campaign.
2CM.105.00 Protection of Captured Transactions and Advices Stored

Test No. 2CM.105.00 Objective: To ensure that when the terminal supports batch data capture, the captured transactions and advices stored in the terminal are not erased or altered until the next reconciliation with the acquiring system. Reference: 2RM.105.0 - Book 4 Section 3.3 - Protection of Captured Transactions and Advices Stored Conditions: Terminal supports batch Data captured Procedure: Several Transactions are performed with the terminal. Transaction stored are read before reconciliation with the acquiring system Pass Criteria: The captured transactions and advices stored in the terminal shall not be erased or altered.
Page 581
2CM.106.00 Clock With Local Date and Time

Test No. 2CM.106.00 Objective: To ensure that Offline-only terminals and offline terminals with online capability have a clock with the local date and time Reference: 2RM.106.0 - Book 4 Section 3.4 - Clock With Local Date and Time Conditions: Terminal is offline only or offline with online capability CDOL1 requests Transaction Date and Transaction Time Procedure: Several Transactions are performed with the terminal. Pass Criteria: Transaction Date and Time shall be coherent.
2CM.107.00 Capability of Terminal Printer

Test No. 2CM.107.00 Objective: To ensure that if present, the printer shall be able to print at least 20 alphanumeric characters per line Reference: 2RM.107.0 - Book 4 Section 3.5 - Capability of Terminal Printer Conditions: Terminal has a printer PAN of LT is 19 digits plus additional padding Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: PAN shall be printed correctly on the receipt
Page 582
2CM.108.00 Terminal Also Equipped With Magnetic Stripe Reader

Test No. 2CM.108.00 Objective: To ensure that terminal is also equipped with a Magstripe Reader except for cardholder controlled terminal or if Payment System rules indicates otherwise Reference: 2RM.108.0 - Book 4 Section 3.6 - Terminal Also Equipped With Magnetic Stripe Reader Conditions: Terminal is not a cardholder controlled terminal Payment System rules do not indicate that magstripe reader is not required Procedure: No condition specified Pass Criteria: Terminal shall be equipped with a Magstripe Reader
2CM.109.00 Magnetic Stripe Reader Using Full Track 1 and/or Track 2

Test No. 2CM.109.00 Objective: To ensure that if present, terminal Magstripe Reader is able to read full track 1 and /or track 2 Reference: 2RM.109.0 - Book 4 Section 3.6 - Magnetic Stripe Reader Using Full Track 1 and/or Track 2 Conditions: LT is a magstripe with Track 1 and Track 2 Procedure: Transaction is performed with magstripe LT Pass Criteria: Terminal shall be able to read either Track 1 or Track 2 or both
Page 583
2CM.129.00 PIN Pad Shall Support Entry of 4-12 Digit PIN

Test No. 2CM.129.00 Objective: To ensure that PIN Pad terminal supports 4 to 12 digits PIN Reference: 2RM.129.0 - Book 2 Section 11.1.2 - PIN Pad Shall Support Entry of 4-12 Digit PIN Conditions: LT supports Cardholder verification Terminal supports Offline PIN CVM in LT is Plaintext PIN verification performed by ICC always or Enciphered PIN verification performed by ICC always PIN in LT has various length between 4 and 12 and is presented OK CDOL1 requests TSI and TVR Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion TVR byte 3, bit 8 = 0 ie Cardholder verification failed TSI byte 1, bit 7 = 1 ie Cardholder verification was performed PIN received by LT shall be OK
Page 584
2CM.130.00 Display of Indication of Entry on PIN Pad

Test No. 2CM.130.00 Objective: To ensure that when a display is present on a PIN Pad, an indication of the entry of each digit shall be displayed Reference: 2RM.130.0 - Book 2 Section 11.1.2 - Display of Indication of Entry on PIN Pad Conditions: LT supports Cardholder verification Terminal supports Offline PIN CVM in LT is Plaintext PIN verification performed by ICC always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion An indication of the entry of each digit shall be displayed
Page 585
2CM.131.00 Protection of Values of Entered PIN

Test No. 2CM.131.00 Objective: To ensure that when a display is present on a PIN Pad, the values of the entered PIN are not displayed or disclosed by visible or audible feedback means, in accordance with ISO 9564-1 Reference: 2RM.131.0 - Book 2 Section 11.1.2 - Protection of Values of Entered PIN Conditions: LT supports Cardholder verification Terminal supports Offline PIN CVM in LT is Plaintext PIN verification performed by ICC always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The value of the entered PIN shall not be displayed The value of the entered PIN shall not be disclosed by audible feedback means
Page 586
2CM.137.00 Protection of PIN During Online PIN Verification

Test No. 2CM.137.00 Objective: To ensure that the Terminal enciphers the online PIN according to ISO 9564-1 and transmits it according to the payment systems rules, if the terminal supports online PIN verification Reference: 2RM.137.0 - Book 2 Section 11.1.2 - Protection of PIN During Online PIN Verification Conditions: LT supports Cardholder verification Terminal supports enciphered PIN verified online CVM in LT is enciphered PIN verified online always PIN is presented OK Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The enciphered PIN Data in financial or authorization request message shall contain the PIN entered enciphered according to ISO 9564-1
Page 587
2CM.140.00 Amount Entry Process Separate From PIN Entry Process

Test No. 2CM.140.00 Objective: To ensure that if the Terminal is attended and supports PIN entry, the amount entry process is separate from the PIN entry process Reference: 2RM.141.0 - Book 2 Section 11.1.2 - Amount Entry Process Separate From PIN Entry Process Conditions: LT supports Cardholder verification Terminal is attended terminal Terminal supports Offline PIN CVM in LT is Plaintext PIN verification performed by ICC always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The amount entry process shall be separated from the PIN entry process to avoid any accidental display of a PIN on the terminal display
Page 588
2CM.141.00 Amount Validated by Cardholder

Test No. 2CM.141.00 Objective: To ensure that the Amount entry is validated by the cardholder before entry of the PIN if the Terminal is attended and supports PIN entry and Amount and PIN are entered on the same key pad Reference: 2RM.142.0 - Book 2 Section 11.1.2 - Amount Validated by Cardholder Conditions: LT supports Cardholder verification Terminal is attended terminal Terminal supports Offline PIN Amount and PIN are entered on the same key pad CVM in LT is Plaintext PIN verification performed by ICC always Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The amount entry process shall be validated before the terminal switches to PIN entry
Page 589
2CM.142.00 Enhanced Combined DDA/AC failed at 2nd generate AC

Test No. 2CM.142.00 Objective: To ensure that if Combined DDA/AC Generation failed at the second generate AC, the terminal declines the transaction. Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC Enhanced Combined DDA/AC signature generated in LT is failed LT returns an ARQC in first Generate AC Enhanced Combined DDA/AC signature generated in LT is good for the 1st Generate AC response
Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC Authentication). Pass Criteria: The terminal shall decline the transaction after the 2nd Generate AC.
Page 590
2CM.143.00 Combined DDA/AC generation requested bit in Generate AC

Test No. 2CM.143.00 Objective: To ensure that the terminal sets the combined DDA/AC requested bit to 1b in generate AC if enhanced combined DDA/AC is to be performed Reference: Based on Bulletin N 6 Conditions: Terminal and LT support Enhanced Combined DDA/AC Procedure: Application in LT is selected and transaction is processed with LT (in particular Enhanced Combined DDA/AC Authentication). Pass Criteria: The terminal shall process the transaction until completion In GENERATE AC command, bit 6 of P1 is set to 1b (i.e. Enhanced Combined DDA/AC generation requested)
Page 591
Software Architecture
2CN.004.00 Data Elements are Initialised in Terminal
Test No. 2CN.004.00 Objective: To ensure that the data elements listed in "Data Elements Table" Book 3 Annex Aare initialized in the terminal or obtainable at the time of a transaction Reference: 2RN.004.0 - Book 4 Section 6 - Data Elements are Initialized in Terminal Conditions: CDOL1 requests (several tests can be made since length is too long to return all data: Acquirer Identifier Additional Terminal Capabilities Amount Authorized Amount Other Amount Reference Currency Application Identifier Application Version Number CVM Results Certification Authority Public Key Index Interface Device Serial Number Merchant Category Code Merchant Identifier POS Entry Mode Terminal Capabilities Terminal Country Code Terminal Floor Limit Terminal identification Terminal Risk Management Data Terminal Type Terminal Verification Results Transaction Currency Code Copyright 2002 EMVCo, LLC. All rights reserved Page 592
EMVCo Type Approval - Terminal Level 2 - Test Cases Transaction Currency Exponent Transaction Date Transaction Reference Currency Code Transaction Reference Currency Exponent Transaction Sequence Counter Transaction Status Information Transaction Time Transaction Type Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Data Element returned by the terminal shall have correct format and coherent value Acquirer Identifier Additional Terminal Capabilities Amount Authorized Amount Other Amount Reference Currency Application Identifier Application Version Number CVM Results Certification Authority Public Key Index Interface Device Serial Number Merchant Category Code Merchant Identifier POS Entry Mode Terminal Capabilities Terminal Country Code Terminal Floor Limit Terminal identification Terminal Risk Management Data Terminal Type Terminal Verification Results Transaction Currency Code Copyright 2002 EMVCo, LLC. All rights reserved n 6-11 b b or n 12 b or n 12 b b b b b an 8 n4 ans 15 n2 b n3 b an 8 b n2 b n3 Page 593
EMVCo Type Approval - Terminal Level 2 - Test Cases Transaction Currency Exponent Transaction Date Transaction Reference Currency Code Transaction Reference Currency Exponent Transaction Sequence Counter Transaction Status Information Transaction Time Transaction Type n1 n 6 (YYMMDD) n3 n1 n 4-8 b n 6 (HHMMSS) n2
2CN.012.00 Language Support by Terminal

Test No. 2CN.012.00 Objective: To ensure that the terminal has parameters initialized so that it can identify what language(s) are supported to process the cards Language Preference Reference: 2RN.012.0 - Book 4 Section 6.1 - Language Supported by Terminal Conditions: Several LTs have different Language Preference Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The languages supported by the terminal shall be used if requested by LT in Language Preference
Page 594
2CN.016.00 Terminal Displays Error Message if Verification Process fails

Test No. 2CN.016.00 Objective: To ensure that if operator action is needed, the terminal displays an error message if the verification process fails during the loading of the Certification Authority Public Key Reference: 2RN.016.0 - Book 4 Section 6.2 - Terminal Displays Error Message if Verification Process fails Conditions: Certification Authority Public Key checksum is not good Procedure: Certification Authority Public Key loading is processed Pass Criteria: The terminal shall display an error message
Cardholder and Attendant Interface

2CO.001.00 Terminal Support of Local Language
Test No. 2CO.001.00 Objective: To ensure that the terminal supports the local language which is the language of common usage in the terminals locality or region Reference: 2RO.001.0 - Book 4 Section 7.1 - Terminal Support of Local Language Conditions: LT has Language Preference set according to the terminals locality or region Terminal has a display Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The message displayed shall be in the language of common usage in the terminals locality or region shall be used
Page 595
2CO.002.00 Terminal Display of Messages in Local Language

Test No. 2CO.002.00 Objective: To ensure that the terminal displays the messages to the attendant in the language of common usage in the terminals locality or region Reference: 2RO.002.0 - Book 4 Section 7.1 - Terminal Display of Messages in Local Language Conditions: Terminal is attended and has a display Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The message displayed for the attendant shall be in the language of common usage in the terminals locality or region
2CO.003.00 Terminal Support of Relevant Character Set

Test No. 2CO.003.00 Objective: To ensure that the terminal displays the messages using the relevant character set defined in the corresponding part of ISO 8859 Reference: 2RO.003.0 - Book 4 Section 7.1 - Terminal Support of Relevant Character Set Conditions: Several LTs have different Language Preference Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The languages supported by the terminal (and the LT) shall be used with relevant character set
Page 596
2CO.005.00 Terminal uses language With Highest Preference

Test No. 2CO.005.00 Objective: To ensure that the terminal compare the cards Language Preference with the languages supported in the terminal at the beginning of the transaction and uses the language with the highest preference in the messages displayed to the cardholder if a match is found. Reference: 2RO.005.0 - Book 4 Section 7.1 - Terminal uses language With Highest Preference Conditions: Terminal supports several Languages Several LTs have different Language Preference value with at least one matching language with Terminal (Language Preference is coded so that language with highest priority appears first) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The messages for the cardholder shall be displayed in the Language with highest priority supported by both LT and Terminal
Page 597
2CO.006.00 Terminal Allows Cardholder to Select Language

Test No. 2CO.006.00 Objective: To ensure that the terminal compare the cards Language Preference with the languages supported in the terminal at the beginning of the transaction and allows the cardholder to choose if no match is found and Terminal supports several Languages Reference: 2RO.006.0 - Book 4 Section 7.1 - Terminal Allows Cardholder to Select Language Conditions: Terminal supports several Languages LT have Language Preference value with no matching language with Terminal Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall ask the cardholder to choose his favourite Language
Page 598
2CO.007.00 Terminal Displays Message in Selected Language

Test No. 2CO.007.00 Objective: To ensure that the terminal uses the Language selected by the Cardholder if a Language selection by cardholder occurred Reference: 2RO.007.0 - Book 4 Section 7.1 - Terminal Displays Message in Selected Language Conditions: Terminal supports several Languages LT have Language Preference value with no matching language with Terminal Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall ask the cardholder to choose his favourite Language The messages for the Cardholder shall be displayed in the selected Language
Page 599
2CO.008.00 Terminal Displays Message in Supported Language

Test No. 2CO.008.00 Objective: To ensure that the terminal uses the language it supports if no match is found with card supported Languages and Terminal supports only one Language (Language of common usage in the region) Reference: 2RO.008.0 - Book 4 Section 7.1 - Terminal Displays Message in Supported Language Conditions: Terminal supports only one Language LT have Language Preference value with no matching language with Terminal Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The messages for the Cardholder shall be displayed in the Terminal supported Language (Language of common usage in the region)
2CO.011.00 Terminal Support of Explicit Selection

Test No. 2CO.011.00 Objective: To ensure that the terminal supports explicit selection of application Reference: 2RO.011.0 - Book 4 Section 7.3 - Terminal Support of Explicit Selection Conditions: LT does not have a PSE Terminal and LT have at least one matching application Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a SELECT command for each of the terminal supported application
Page 600
2CO.013.00 Terminal Creates a List of Applications Supported (1)

Test No. 2CO.013.00 Objective: To ensure that applications mutually supported by card and terminal are displayed using the Application Preferred Name if the terminal supports cardholder application selection and if Application Preferred Name is present as well as the Issuer Code Table Index to be used Reference: 2RO.013.0 - Book 4 Section 7.3 - Terminal Creates a List of Applications Supported (1) Conditions: LT and Terminal have several mutually supported applications LT applications have a priority order specified in Application Priority Indicator Terminal supports selection of application by the Cardholder LT applications have Application Preferred Name and Issuer Code Table Index Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall display the list of applications mutually supported using the Application preferred Name and corresponding Issuer Table Index for each Application
Page 601
2CO.014.00 Terminal Creates a List of Applications Supported (2)

Test No. 2CO.014.00 Objective: To ensure that applications mutually supported by card and terminal are displayed using the Application Label if the terminal supports cardholder application selection and if Application Preferred Name is absent Reference: 2RO.013.1 - Book 4 Section 7.3 - Terminal Creates a List of Applications Supported (2) Conditions: LT and Terminal have several mutually supported applications LT applications have a priority order specified in Application Priority Indicator Terminal supports selection of application by the Cardholder LT applications have not Application Preferred Name Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The Terminal shall display the list of applications mutually supported using the Application Label and common Issuer Table Index
Page 602
2CO.015.05 Terminal Presents Application List

Test No. 2CO.015.05 Objective: To ensure that if the card returns SW1 SW2 other than 9000 in response to the SELECT command, a terminal allowing cardholder selection or confirmation should display the Try again message and presents to the cardholder the list of applications supported by both the ICC and the terminal without this application. Reference: 2RO.015.5 - Book 4 Section 7.3 - Terminal Presents Application List Conditions: Terminal allows cardholder selection or confirmation Terminal and LT have several mutually supported applications LT returns SW1SW2 different from '90 00' in response to the Final SELECT command Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: The terminal shall present to the cardholder the list of all applications supported by both the ICC and the terminal without this application. The terminal should display the Try again message.
Page 603
2CO.016.00 Terminal Selects Application With Next Highest priority

Test No. 2CO.016.00 Objective: To ensure that if the terminal does not support cardholder application selection, and if selected application returned status different from 90 00, it selects the application with second priority from the list of application mutually supported by card and terminal and not requiring cardholder confirmation Reference: 2RO.016.0 - Book 4 Section 7.3 - Terminal Selects Application With Next Highest priority Conditions: LT and Terminal have several mutually supported applications (at least 3) LT applications have a priority order specified in Application Priority Indicator Terminal does not support selection of application by the Cardholder Application with highest priority in the list of mutually supported applications requires Cardholder confirmation LT returns status different from 9000 to the SELECT command sent to select Application with second highest priority in the list of mutually supported applications (the SELECT command sent for this application during the phase where terminal looks for mutually supported application works correctly) Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion After the phase where terminal looks for the applications present in the card, the LT shall receive a SELECT command for the application with second highest priority in the list of mutually supported application and LT shall return status different from 90 00 The LT shall receive another SELECT command for the application with third highest priority in the list of mutually supported application
Page 604
2CO.017.00 Application Used Identified on Receipt

Test No. 2CO.017.00 Objective: To ensure that the terminal prints partial Application PAN (or the full PAN, if allowed by payment system rules) and the AID on the receipt Reference: 2RO.017.0 - Book 4 Section 7.3 - Application Used Identified on Receipt Conditions: Terminal is equipped with a printer Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall print a receipt with partial Application PAN (or the full PAN, if allowed by payment system rules) and the AID
2CO.018.00 Data Printed on Receipt

Test No. 2CO.018.00 Objective: To ensure that the terminal prints the AID in hexadecimal characters on the receipt Reference: 2RO.018.0 - Book 4 Section 7.3 - Data Printed on Receipt Conditions: Terminal is equipped with a printer Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall print a receipt with the AID in hexadecimal characters
Page 605
2CO.019.00 Authorization Message Used

Test No. 2CO.019.00 Objective: To ensure that the terminal uses an authorization message when transactions are batch data captured Reference: 2RO.020.0 - Book 4 Section 8.1 - Authorization Message Used Conditions: Transaction is performed online Transactions are batch data captured Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall prepare and transmit an authorization request message
2CO.020.00 Financial Transaction Message Used

Test No. 2CO.020.00 Objective: To ensure that the terminal uses a Financial Transaction message when online data capture is performed by the acquirer Reference: 2RO.021.0 - Book 4 Section 8.1 - Financial Transaction Message Used Conditions: Transaction is performed online Terminal supports online data capture Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall prepare and transmit a financial transaction message
Page 606
2CO.021.00 Offline Advice message Conveyed

Test No. 2CO.021.00 Objective: To ensure that the terminal conveys offline advices within batch data capture when supported. Reference: 2RO.022.0 - Book 4 Section 8.1 - Offline Advice message Conveyed Conditions: Terminal supports batch data capture. Terminal supports Advices LT requests an Advice in response to First GENERATE AC Procedure: Application in LT is selected and transaction is processed with LT. Pass Criteria: Terminal shall convey offline advices.
2CO.023.00 Reversal Used

Test No. 2CO.023.00 Objective: To ensure that the terminal transmits reversal messages realtime Reference: 2RO.023.1 - Book 4 Section 8.1 - Reversal Message Used Conditions: First GENERATE AC response from LT is ARQC Terminal supports online data capture Issuer returns incorrect authorization responses Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall prepare and transmit a Reversal
Page 607
2CO.025.00 Terminal Issues a 2nd GENERATE AC Command When Unable to Go Online (1)
Test No. 2CO.025.00 Objective: To ensure that the terminal set Authorization Response Code to Unable to go online, offline accepted and issues a second GENERATE AC indicating TC if the terminal accepts the transaction after not having been able to go online Reference: 2RO.025.0 - Book 4 Section 8.2.1 - Terminal Issues a 2 Command When Unable to Go Online (1)
nd
GENERATE AC
Conditions: Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have all bits set to 0b First GENERATE AC response from LT is ARQC Terminal is unable to go online (no response received from issuer for instance) CDOL2 requests Authorization response Code Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting a TC Authorization response Code shall contain to Unable to go online, offline accepted
Page 608
2CO.026.00 Terminal Issues a 2nd GENERATE AC Command When Unable to Go Online (2)
Test No. 2CO.026.00 Objective: To ensure that the terminal set Authorization Response Code to Unable to go online, offline declined and issues a second GENERATE AC indicating AAC if the terminal declines the transaction after not having been able to go online Reference: 2RO.026.0 - Book 4 Section 8.2.1 - Terminal Issues a 2nd GENERATE AC Command When Unable to Go Online (2) Conditions: Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have some bits set to 1b AIP, and Data in the LT are populated so that bits set to 1b in Issuer Action Code Default are set to 1b in the TVR during transaction processing (several tests can also be made for different bits set) First GENERATE AC response from LT is ARQC Terminal is unable to go online (no response received from issuer for instance) CDOL2 requests Authorization response Code Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive a second GENERATE AC command requesting an AAC Authorization response Code shall contain to Unable to go online, offline declined
Page 609
2CO.027.00 Issuer Authentication was performed Bit is Set

Test No. 2CO.027.00 Objective: To ensure that the terminal does not issue EXTERNAL AUTHENTICATE command to the card and sets the Issuer authentication was performed bit in the Transaction Status Information to 0, if response received does not contain the Issuer Authentication Data Reference: 2RO.027.0 - Book 4 Section 8.2.2 - Issuer Authentication was performed Bit is Set Conditions: First GENERATE AC response from LT is ARQC Terminal has online capabilities Response from Issuer does not contain Issuer Authentication Data CDOL2 requests TSI Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall not receive an EXTERNAL AUTHENTICATE command TSI byte 1, bit 5 = 0 ie the Issuer Authentication was not performed
Page 610
2CO.028.00 Terminal Continues Processing Based on Authorization Response Code

Test No. 2CO.028.00 Objective: To ensure that the terminal continue the processing of the transaction according to the Authorization Response Code if transaction is performed online. Reference: 2RO.028.0 - Book 4 Section 8.2.2 - Terminal Continues Processing Based on Authorization Response Code Conditions: First GENERATE AC response from LT is ARQC Terminal has online capabilities CDOL2 requests Authorization Response Code 4 values of Authorization Response Code are tested 1. Online approved 2. Online declined 3. Referral Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Authorization Response Code shall be the same as the one received from issuer Depending on Authorization Response Code received the terminal shall 1. send a second GENERATE AC requesting TC 2. send a second GENERATE AC requesting AAC 3. display Call Your Bank message
Page 611
2CO.029.00 Repeat of Authorization Request

Test No. 2CO.029.00 Objective: To ensure that the terminal processes the transaction as being unable to go online if it has repeated the authorization request and the authorization response received is still incorrect. Reference: 2RO.029.0 - Book 4 Section 8.2.3 - Repeat of Authorization Request Conditions: Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have some bits set to 1b AIP, and Data in the LT are populated so that bits set to 1b in Issuer Action Code Default are set to 1b in the TVR during transaction processing (several tests can also be made for different bits set) First GENERATE AC response from LT is ARQC Issuer returns incorrect authorization responses Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall repeat the authorization request after incorrect or absent response The LT shall receive a second GENERATE AC command requesting an AAC
Page 612
2CO.030.00 Terminal Issues a 2nd GENERATE AC Command (1)

Test No. 2CO.030.00 Objective: To ensure that the terminal set Authorization Response Code to Unable to go online, offline accepted and issues a second GENERATE AC indicating TC if it has repeated the authorization request and the authorization response received is still incorrect and if the terminal accepts the transaction. Reference: 2RO.030.0 - Book 4 Section 8.2.3 - Terminal Issues a 2 Command (1)
nd
GENERATE AC
Conditions: Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have all bits set to 0 First GENERATE AC response from LT is ARQC CDOL2 requests Authorization response Code Issuer returns incorrect authorization responses Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall repeat the authorization request after incorrect or absent response The LT shall receive a second GENERATE AC command requesting a TC Authorization Response Code shall contain to Unable to go online, offline accepted
Page 613
2CO.031.00 Terminal Issues a 2nd GENERATE AC Command (2)

Test No. 2CO.031.00 Objective: To ensure that the terminal set Authorization Response Code to Unable to go online, offline declined' and issues a second GENERATE AC indicating AAC if it has repeated the authorization request and the authorization response received is still incorrect if the terminal declines the transaction. Reference: 2RO.031.0 - Book 4 Section 8.2.3 - Terminal Issues a 2 Command (2)
nd
GENERATE AC
Conditions: Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have some bits set to 1b AIP, and Data in the LT are populated so that bits set to 1b in Issuer Action Code Default are set to 1b in the TVR during transaction processing (several tests can also be made for different bits set) First GENERATE AC response from LT is ARQC CDOL2 requests Authorization response Code Issuer returns incorrect authorization responses Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall repeat the authorization request after incorrect or absent response The LT shall receive a second GENERATE AC command requesting an AAC Authorization response Code shall contain to Unable to go online, offline declined
Page 614
2CO.032.00 Terminal Sends Reversal Message

Test No. 2CO.032.00 Objective: To ensure that the terminal sends a reversal message to the issuer if online data capture is performed and the terminal has repeated the authorization request and the authorization response received is still incorrect. Reference: 2RO.032.0 - Book 4 Section 8.2.3 - Terminal Sends Reversal Message Conditions: First GENERATE AC response from LT is ARQC Issuer returns incorrect authorization responses Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall repeat the authorization request after incorrect or absent response The terminal shall prepare and transmit a Reversal message in the format described in Book 4 - Tables 14 and 15
Page 615
2CO.033.00 Terminal Creates Financial Record

Test No. 2CO.033.00 Objective: To ensure that the terminal creates a financial record if a reversal has been sent and transaction is finally approved. Reference: 2RO.033.0 - Book 4 Section 8.2.3 - Terminal Creates Financial Record Conditions: Online Data capture is performed Terminal Action Codes and Issuer Action Code Denial and Online have all bits set to 0b Issuer Actions Codes Default have all bits set to 0b First GENERATE AC response from LT is ARQC Issuer returns incorrect authorization responses The LT shall return a TC to the second GENERATE AC command Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion Terminal shall repeat the authorization request after incorrect or absent response The LT shall receive a second GENERATE AC command requesting a TC The terminal shall prepare Financial message in the format described in Book 4 - Tables 14 and 15
Page 616
2CO.034.00 Terminal Terminates Processing of Issuer Script

Test No. 2CO.034.00 Objective: To ensure that the terminal terminates the processing of a script if there is a script length error or syntax error. Reference: 2RO.034.0 - Book 4 Section 8.2.4 - Terminal Terminates Processing of Issuer Script Conditions: Transaction is performed online Issuer sends scripts: * Test 1: script has a script length error (total length is larger than supported length) * Test 2: script has a syntax error and it is not possible to parse the script into single script commands Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall not receive any command of script for test 1 and 2
Page 617
2CO.035.00 Terminal Reports in Issuer Script results

Test No. 2CO.035.00 Objective: To ensure that the terminal terminates the processing if Issuer Script does not parse correctly and reports scripts error in Issuer Script Results Reference: 2RL.019.8 - Book 1 Section 6 - Constructed Data Objects do not parse correctly: Issuer Script 2RO.036.0 - Book 4 Section 8.2.4 - Terminal Reports in Issuer Script results Conditions: Transaction is performed online Authorization or financial response contains one or several scripts which does not parse correctly Issuer sends script which has a syntax error and it is not possible to parse the script into single script commands (several tests can be made with bad Tag, bad length, Tag located at a wrong position...) Script received has a readable Script Identifier Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The terminal shall terminate the bad parsed Issuer script processing and continue subsequent Scripts if readable Issuer Script Results (contained in Financial Confirmation message or Batch Data Captured message) shall not perform the script.
Page 618
2CO.036.00 Terminal Continues Processing any Subsequent Issuer Script

Test No. 2CO.036.00 Objective: To ensure that the terminal continues processing of any subsequent script if the script currently processed has a syntax error. Reference: 2RO.037.0 - Book 4 Section 8.2.4 - Terminal Continues Processing any Subsequent Issuer Script Conditions: Transaction is performed online Issuer sends back 2 scripts: * script 1 has a syntax error and it is not possible to parse the script into single script commands * script 2 is good Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: The terminal shall process the transaction until completion The LT shall receive command for script 2 only
Page 619
Coding of Terminal Data Elements

2CP.001.00 Terminal Type
Test No. 2CP.001.00 Objective: To ensure that the terminal has Terminal Type coded according to its effective type. Reference: 2RP.001.0 - Book 4 Annex A - Terminal Type Conditions: CDOL1 requests Terminal Type and Terminal Capabilities Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: Terminal capabilities shall be coded according to the terminal supported features indicated below: * Attended Terminal * Unattended Terminal x1 or x2 or x3 x4 or x5 or x6
* Terminal operated by Financial Institutions 1x * Terminal operated by Merchant * Terminal operated by Cardholder * Online only * Offline with online capabilities * Offline only 2x 3x x1 or x4 x2 or x5 x3 or x6
Page 620
2CP.002.00 Terminal Capabilities

Test No. 2CP.002.00 Objective: To ensure that the terminal has Terminal capabilities coded according to its effective Capabilities Reference: 2RP.002.0 - Book 4 Annex A - Terminal Capabilities Conditions: CDOL1 requests Terminal Capabilities Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: Terminal capabilities shall be coded according to the terminal supported features indicated below:
* Manual Key entry * Magnetic stripe * IC with contacts * Plaintext PIN verified by ICC * Enciphered PIN online * Signature * Offline Enciphered PIN verified by ICC * No CVM required * Static Data Authentication * Dynamic Data Authentication * Card capture
byte 1, b8 = 1 byte 1, b7 = 1 byte 1, b6 = 1 byte 2, b8 = 1 byte 2, b7 = 1 byte 2, b6 = 1 byte 2, b5 = 1 byte 2, b4 = 1 byte 3, b8 = 1 byte 3, b7 = 1 byte 3, b6 = 1
Page 621
2CP.003.00 Additional Terminal Capabilities

Test No. 2CP.003.00 Objective: To ensure that the terminal has Additional Terminal capabilities coded according to its effective Capabilities Reference: 2RP.003.0 - Book 4 Annex A - Additional Terminal Capabilities Conditions: CDOL1 requests Additional Terminal Capabilities Procedure: Application in LT is selected and transaction is processed with LT Pass Criteria: Transaction Type Capabilities shall be coded according to the terminal supported features indicated below: * Cash * Goods * Services * Cashback * Inquiry * Transfer * Payment * Administrative * Numeric Keys * Alphabetical and special characters keys * Command Keys * Function Keys * Print, attendant * Print, cardholder * Display, attendant * Display, cardholder * Code table 10 Copyright 2002 EMVCo, LLC. All rights reserved byte 1, b8 = 1 byte 1, b7 = 1 byte 1, b6 = 1 byte 1, b5 = 1 byte 1, b4 = 1 byte 1, b3 = 1 byte 1, b2 = 1 byte 1, b1 = 1 byte 3, b8 = 1 byte 3, b7 = 1 byte 3, b6 = 1 byte 3, b5 = 1 byte 4, b8 = 1 byte 4, b7 = 1 byte 4, b6 = 1 byte 4, b5 = 1 byte 4, b2 = 1 Page 622
EMVCo Type Approval - Terminal Level 2 - Test Cases * Code table 9: * Code table 8: * Code table 7: * Code table 6 * Code table 5: * Code table 4: * Code table 3: * Code table 2: * Code table 1: byte 4, b1 = 1 byte 5, b8 = 1 byte 5, b7 = 1 byte 5, b6 = 1 byte 5, b5 = 1 byte 5, b4 = 1 byte 5, b3 = 1 byte 5, b2 = 1 byte 5, b1 = 1
< End Of The Document>
Page 623

Emv2000 L2 2.0

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Emv2000 L2 2.0

Transféré par

Droits d'auteur :

Formats disponibles

EMVCo Type Approval - Terminal Level 2 - Test Cases

EMVCo Type Approval Terminal Level 2 Test Cases

Version 2.0 January 31, 2002

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Version 1.0 2.0

Date August 31, 2000 January 31, 2002

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

SECURITY ASPECTS ............................................................................................................................. 139

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

DATA OBJECTS ...................................................................................................................................... 237

SECURITY MECHANISMS ................................................................................................................... 239 APPROVED CRYPTOGRAPHIC ALGORITHMS ............................................................................. 240

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Abbreviations and Notations

LEN Lr l.s. m.s. NCA NI

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

Copyright 2002 EMVCo, LLC. All rights reserved

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright 2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval - Terminal Level 2 - Test Cases

2CS.001.00 Mandatory Command Set

All TAC (Denial/online/default) in terminal are setup to '00 00 00 00 00'