emv2000-l2-2.0

EMVCo Type Approval - Terminal Level 2 - Test Cases

Copyright �2002 EMVCo, LLC. All rights reserved

EMVCo Type Approval Terminal Level 2 Test Cases __________________________________________________

Version 2.0 January 31, 2002



Legal Notice

This document summarizes EMVCo’s present plans for type approval testing servicesand 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 bindingobligations upon EMVCo or any third party regarding testing services or EMVCoapproval, which obligations will exist, if at all, pursuant to separate written agreementsexecuted by EMVCo and such third parties. In the absence of a written bindingagreement pursuant to which EMVCo has agreed to perform testing services for avendor or to permit a third party to act as a test laboratory, no vendor, test laboratory norany other third party should detrimentally rely on this document, nor shall EMVCo beliable for any such reliance.

No vendor, test laboratory nor other third party may refer to a product, service or facilityas 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 orother third party or its products, services, or facilities, except to the extent and subject tothe terms, conditions and restrictions expressly set forth in a written agreement withEMVCo, or in an approval letter issued by EMVCo. All other references to EMVCoapproval are strictly and actively prohibited by EMVCo.

Under no circumstances should EMVCo type approval, when granted, be construed toimply any endorsement or warranty regarding the functionality, quality, or performanceof any particular product or service, and no party shall state or imply anything to thecontrary. EMVCo specifically disclaims any and all representations and warranties withrespect to products that have received approval and to the type approval processgenerally, including, without limitation, any implied warranties of merchantability,fitness for purpose or noninfringement. All rights and remedies relating to productsand services that have received EMVCo type approval are provided solely by the partiesselling or otherwise providing such products or services, and not by EMVCo, andEMVCo accepts no liability whatsoever in connection with such products and services.Unless otherwise agreed in writing by EMVCo, this document and matter containedherein, including all products and services contemplated by this document are providedon an “as-is” basis, “with all faults” and with no warranties whatsoever, and EMVCospecifically disclaims any implied warranties of merchantability, fitness for purpose,or noninfringement.



Version History

Version Date Revision Description

1.0 August 31, 2000 Initial Publication

2.0 January 31, 2002 Test conformance with EMV2000 ICC Specificationfor Payment Systems Version 4.0 dated December,2000.



Table of Content

SCOPE ......................................................................................................................................................... 20

REFERENCED DOCUMENTS................................................................................................................. 21

ABBREVIATIONS AND NOTATIONS................................................................................................... 22

GLOBAL GLOSSARY............................................................................................................................... 24

COMMAND SYNTAX ............................................................................................................................... 35

2CS.001.00 Mandatory Command Set ............................................................................................... 36 2CS.002.00 Select Next Command..................................................................................................... 38 2CS.003.00 Internal Authenticate Command..................................................................................... 40 2CS.004.00 Verify Command............................................................................................................. 42 2CS.005.00 Get Challenge................................................................................................................. 44 2CS.006.00 Get Data ......................................................................................................................... 46 2CS.007.00 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



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



APPLICATION SELECTION................................................................................................................. 106

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

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

2CC.003.00 Terminal shall be able to store 6 CA Index per RID.................................................... 139 2CC.004.00 Algorithm For SDA...................................................................................................... 140 2CC.006.00 Bit Length of all Moduli ............................................................................................... 141 2CC.007.00 Value of Certification Authority Public Key Exponent ................................................ 142



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



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

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

2CE.001.00 Length field: 1 byte ...................................................................................................... 237 2CE.001.01 Length field: 2 bytes ..................................................................................................... 237 2CE.001.02 Length field: 3 bytes ..................................................................................................... 238

SECURITY MECHANISMS ................................................................................................................... 239

2CG.002.00 Signature verification .................................................................................................. 239

APPROVED CRYPTOGRAPHIC ALGORITHMS ............................................................................. 240

2CH.001.00 The Relationship Between the Lengths of the CA, Issuer, and ICC Public Keys......... 240 2CH.002.00 Coding the Public Key Algorithm Indicator ................................................................ 241 2CH.003.00 Upper bound for size of moduli ................................................................................... 242



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 CombinedDDA / 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



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 isperformed 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 isperformed (1) 290 2CJ.027.00 Rules for Processing the records identified by the AFL, when the Offline DDA isperformed (2) 291 2CJ.028.00 Rules for Processing the records identified by the AFL, when the Offline SDA isperformed (1) 292 2CJ.029.00 Rules for Processing the records identified by the AFL, when the Offline SDA isperformed (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 CountryCode 306 2CJ.046.00 Transaction type is a Cash transaction, and Issuer Country Code = Terminal CountryCode (implied) 307 2CJ.047.00 Transaction type is a Cash transaction, and Issuer Country Code differs from TerminalCountry Code 308 2CJ.048.00 Transaction type is a Cash transaction, and Issuer Country Code differs from TerminalCountry Code (implied) .......................................................................................................................... 309 2CJ.049.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal CountryCode 310 2CJ.050.00 Transaction type is a Purchase of goods, and Issuer Country Code = Terminal CountryCode (implied) 311 2CJ.051.00 Transaction type is a Purchase of goods, and Issuer Country Code differs fromTerminal Country Code .......................................................................................................................... 312 2CJ.052.00 Transaction type is a Purchase of goods, and Issuer Country Code differs fromTerminal Country Code (implied)........................................................................................................... 313 2CJ.053.00 Transaction type is a Purchase of services, and Issuer Country Code = TerminalCountry Code 314



2CJ.054.00 Transaction type is a Purchase of services, and Issuer Country Code = TerminalCountry Code (implied) .......................................................................................................................... 315 2CJ.055.00 Transaction type is a Purchase of services, and Issuer Country Code differs fromTerminal Country Code .......................................................................................................................... 316 2CJ.056.00 Transaction type is a Purchase of services, and Issuer Country Code differs fromTerminal Country Code (implied)........................................................................................................... 317 2CJ.057.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal CountryCode 318 2CJ.058.00 Transaction has a Cashback amount, and Issuer Country Code = Terminal CountryCode (implied) 319 2CJ.059.00 Transaction type is a Cashback amount, and Issuer Country Code differs from TerminalCountry Code 320 2CJ.060.00 Transaction type is a Cashback amount, and Issuer Country Code differs from TerminalCountry 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 Xvalue 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 Xvalue 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 Xvalue 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 Xvalue when transaction amount is greater than X. ................................................................................. 339 2CJ.078.01 Supported CVR condition: If Transaction is in the application currency and is over Xvalue when transaction amount is less than X. ....................................................................................... 340 2CJ.078.02 Supported CVR condition: If Transaction is in the application currency and is over Xvalue when transaction amount is equal to X. ........................................................................................ 341 2CJ.079.00 Supported CVR condition: If Transaction is in the application currency and is under Yvalue 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 Yvalue 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 Yvalue 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 Yvalue 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 Yvalue 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 Yvalue when the transaction amount is less than Y. ................................................................................. 347



2CJ.081.01 Random Transaction Selection: Transaction Amount Less than the Threshold Value forBiased Random Selection ....................................................................................................................... 348 2CJ.081.02 Random Transaction Selection: Transaction Amount Less than the Threshold Value forBiased Random Selection ....................................................................................................................... 349 2CJ.081.03 Random Transaction Selection: Transaction Amount Equal to or Greater than theThreshold 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 theThreshold 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 offlinePlaintext PIN 354 2CJ.083.02 Non Supported CVR condition: If Terminal supports the CVM and CVM is offlineEnciphered PIN355 2CJ.083.03 Non Supported CVR condition: If Terminal supports the CVM and CVM is onlineEnciphered PIN356 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 offlinePlaintext PIN and Signature................................................................................................................... 358 2CJ.083.06 Non Supported CVR condition: If Terminal supports the CVM and CVM is offlineEnciphered PIN and Signature............................................................................................................... 359 2CJ.083.07 No Supported CVR condition: If Terminal supports the CVM and CVM is No CVMRequired 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 (Plaintext PIN verified by ICC supported) ...................................................................................................... 365 2CJ.088.01 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC (Plaintext PIN verified by ICC not supported) ................................................................................................ 366 2CJ.089.00 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (EncipheredPIN Online supported)............................................................................................................................ 367 2CJ.089.01 Second byte of CVR satisfied and CVM Code is Enciphered PIN Online (EncipheredPIN Online not supported)...................................................................................................................... 368 2CJ.090.00 Second byte of CVR satisfied and CVM Code is Plain text PIN verified by ICC andsignature (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 andsignature (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 andsignature (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 andsignature (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 issupported) 377



2CJ.094.01 Second byte of CVR satisfied and CVM Code is No CVM required (No CVM required isnot 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 ismalfunctioning 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 ismalfunctioning 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 isexceeded 399 2CJ.120.00 Transaction log entry with the same PAN is available and Terminal Floor Limit is notexceeded (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 isexceeded 403 2CJ.128.00 Transaction log entry with the same PAN is not available and Terminal Floor Limit isnot 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



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 anARQC 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 requestsan 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 requestsan 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 ‘71’459 2CJ.200.00 SWI in the Status Code is different from ‘90’, ‘62’, or ‘63’ and Issuer Script tag is ‘72’460 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



2CK.003.00 CDOL requests a TC Hash Value and TDOL is present in the ICC............................ 466 2CK.004.00 CDOL requests a TC Hash Value and TDOL is not present in the ICC...................... 467 2CK.005.00 CDOL requests a TC Hash Value and neither TDOL nor default TDOL is present.... 468 2CK.006.00 CDOL requests a TC Hash Value during the second GENERATE AC........................ 469 2CK.007.00 Terminal requests a TC on first GENERATE AC ........................................................ 470 2CK.008.00 Terminal requests an ARQC on first GENERATE AC................................................. 470 2CK.009.00 Terminal requests an AAC on first GENERATE AC.................................................... 471 2CK.010.00 Card responds with an ARQC on first GENERATE AC .............................................. 471 2CK.011.00 Card responds with an AAR on first GENERATE AC ................................................. 472 2CK.012.00 Card responds with a TC on first GENERATE AC...................................................... 473 2CK.013.00 Card responds with a AAC on first GENERATE AC ................................................... 473 2CK.015.00 Terminal requests an AAC on second GENERATE AC............................................... 474 2CK.017.00 Cryptogram at a higher level than requested (1)......................................................... 474 2CK.018.00 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 arepresent 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 SystemDirectory 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 AUTHENTICATEresponse template ................................................................................................................................... 500 2CL.036.00 Dates are out of the range............................................................................................ 501



2CL.037.00 Data that must be in a specific range of values but are not: SFI ................................. 501 2CL.038.00 Data that must be in a specific range of values but are not: Issuer Code Table Index 502 2CL.044.00 CVM List with no Cardholder Verification Rules ........................................................ 502 2CL.046.00 AFL with no entries ...................................................................................................... 503 2CL.047.00 AFL with an incorrect SFI ........................................................................................... 503 2CL.048.00 AFL with an incorrect starting record number ............................................................ 504 2CL.049.00 AFL with an incorrect ending record number.............................................................. 504 2CL.050.00 AFL with an incorrect number of records participating in Offline Data Authentication505 2CL.052.00 ISO Padding: right padding......................................................................................... 505 2CL.053.00 ISO Padding: padding before Data object................................................................... 506 2CL.054.00 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 forPIN Try Counter 522 2CM.020.01 Online PIN When PIN Try Limit is Exceeded and the Terminal does not support GETDATA 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 TransactionOnline 536 2CM.036.00 Terminal Completes Transaction When Card Indicated Approval ............................ 536 2CM.037.00 Terminal Declines Transaction When Card Indicated Denial................................... 537



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 iscaptured 538 2CM.041.00 Advice is Requested by Card and is Supported by the Terminal and transaction is notcaptured 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 TransactionResponse 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 Referralinitiated 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 Processinitiated 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 aReferral 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



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



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



Scope

Integrated Circuit Card Specification for Payment System Version 4.0 is now divided in 4books:

� 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 anIntegrated Circuit Card (ICC) and a terminal, from the selection of an application in theICC to the completion of the transaction.

Book 3 defines the format of ICC commands used during the transaction flow betweenthe ICC and terminal. Also defined is the transaction flow and associated data for anapplication compliant with the EMV specifications.

Finally Book 4 defines the characteristics of a Terminal that supports an ICC conformingto the two previous specifications mentioned.

The 4 Books are divided in testable requirements listed in the 'EMVCo Terminal Level2 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 todetermine whether the terminal meets the requirements stated in EMV2000 IntegratedCircuit 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 validEMV payment application and functional testing dependent of the presence of the EMVpayment application.

Terminal/host protocol (if present) is not tested since requirements for terminalcommunication with external components is not defined by EMV specifications.

If any special conditions are required for a specific test case, these conditions aredescribed in the test case.

The intended audience for this document are EMVCo accredited laboratories, EMVapplication providers, acquiring members or merchants. Although acquiring membersand merchants may reference this document, type approval testing oriented towardEMV application providers.



Referenced Documents

[N1] EMV 2000 Integrated Circuit Card Specification forPayment Systems - Book 1 - Application IndependentICC to Terminal Interface Requirements

Version 4.0 - December2000

[N2] EMV 2000 Integrated Circuit Card ApplicationSpecification for Payment Systems - Book 2 -Security and Key Management


[N3] EMV 2000 Integrated Circuit Card TerminalSpecification for Payment Systems - Book 3 -Application Specification


[N4] EMV 2000 Integrated Circuit Card TerminalSpecification for Payment Systems - Book 4 -Cardholder, Attendant, and Acquirer InterfaceRequirements




Abbreviations and Notations

APDU Application Protocol Data Unit

ATR Answer to Reset

C-APDU Command APDU

CLA Class Byte of the Command Message

C-TPDU Command TPDU

EMV Europay, MasterCard, Visa

ICC Integrated Circuit Card

IFD Interface Device

INS Instruction Byte of Command Message

ISO International Organization for Standardization

Lc Exact Length of Data Sent by the TAL in a Case 3 or 4 Command

Le Maximum Length of Data Expected by the TAL in Response to a Case 2or 4 Command

Licc Exact Length of Data Available or Remaining in the ICC (as Determinedby the ICC) to be Returned in Response to the Case 2 or 4 CommandReceived by the ICC

LEN Length

Lr Length of Response Data Field

l.s. Least Significant

m.s. Most Significant

NCA Length of the Certification Authority Public Key Modulus

NI Length of the Issuer Public Key Modulus



NIC Length of the ICC Public Key Modulus

P1 Parameter 1

P2 Parameter 2

P3 Parameter 3

PI Issuer Public Key

PIC ICC Public Key

R-APDU Response APDU

RST Reset

R-TPDU Response TPDU

SCA Certification Authority Private Key

SI Issuer Private Key

SIC ICC Private Key

SW1 Status Word One

SW2 Status Word Two

TPDU Transport Protocol Data Unit



Global Glossary Accelerated Revocation- A key revocation performed date sooner than the publishedkey expiry date.

Accreditation - Formal recognition by EMVCo that an auditor or testing laboratory iscompetent to carry out specific functions defined in EMVCo type approval procedures.

Acquirer - A financial institution that supports merchants by providing services forprocessing payment card transactions.

Acquirer System - A logical entity that provides electronic commerce services to themerchants in support of the acquirer and interfaces to the acquirer to support theauthorization and capture of electronic commerce transactions.

Answer to Reset (ATR) - A string of bytes sent by the integrated circuit card (ICC) inresponse to the reset by the terminal. These bytes convey information to the terminalthat define certain characteristics of the communication to be established between theICC and the terminal.

Application - The application protocol between the card and the terminal and its relatedset 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 aresponse message.

Asymmetric Cryptographic Technique - A cryptographic technique that uses tworelated transformations, a public transformation (defined by the public key) and a privatetransformation (defined by the private key). The two transformations have the propertythat, given the public transformation, it is computationally infeasible to derive the privatetransformation.

Auditor - Independent impartial entity that verifies test laboratory conformance toEMVCo defined type approval procedures.

Authentication- The provision of assurance of the claimed identity of an entity [ISO/IEC10181-2: 1996].

Authorization- The process by which a properly appointed person or persons grantspermission to perform some action on behalf of an organization. This process assessestransaction risk, confirms that a given transaction does not raise the account holder'sdebt above the account's credit limit, and reserves the specified amount of credit.(When a merchant obtains authorization, payment for the authorized amount isguaranteed - provided that the merchant followed the rules associated with theauthorization process.)



Authorization Reversal - A transaction sent when a previous authorization needs to becanceled (a full reversal) or decreased (a partial reversal). A full reversal will be usedwhen the transaction can not be completed, such as when the cardholder cancels theorder or the merchant discovers that the goods are no longer available, as whendiscontinued. A partial reversal will be used when the authorization was for the entireorder 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 prologuefield, 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 interactwith the cardholder, his or her IC Card, and a SET Merchant Server in order toparticipate in EMV chip electronic commerce.

Certificate: The public key and identity of an entity together with some otherinformation, rendered unforgeable by signing with the secret key of the certificationauthority which issued that certificate.

Certificate Revocation: The process of revoking an otherwise valid certificate by theentity that issued that certificate.

Certification Authority: A centre trusted to create and assign public key certificateswhich 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 publickey 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 othersignals to the ICC are raised from the inactive state and the reset (RST) signal isapplied.

Command - A message sent by the terminal to the ICC that initiates an action andsolicits a response from the ICC.

Compromise: The breaching of secrecy or security.

Concatenation - Two elements are concatenated by appending the bytes from thesecond element to the end of the first. Bytes from each element are represented in theresulting string in the same sequence in which they were presented to the terminal bythe ICC, that is, most significant byte first. Within each byte bits are ordered from mostsignificant bit to least significant. A list of elements or objects may be concatenated byconcatenating the first pair to form a new element, using that as the first element toconcatenate with the next in the list, and so on.



Conformance - Meeting all the requirements (and also any optional requirements) thatthe interface module (IFM) provider instituted of that specification.

Contact - A conducting element ensuring galvanic continuity between integratedcircuit(s) and external interfacing equipment.

Contact Interface - The area where a contact if the interface device (IFD) physicallytouches a contact on the integrated circuit card (ICC) allowing an electrical current toflow between the contacts.

Cryptogram - Result of a cryptographic operation.

Cryptography- The practice of digitally "scrambling" a message using a secret key orkeys.

These keys are used to unscramble or decrypt the message.

Cryptoperiod: Defined period of time during which a specific cryptographic key isauthorized for use, or during which time the cryptographic keys for a given system mayremain in effect. (ISO 8908)

Cryptographic Algorithm - An algorithm that transforms data in order to hide or revealits information content.

Data Integrity - The property that data has not been altered or destroyed in anunauthorised manner

Data Key (KD): Cryptographic key used for the encipherment, decipherment orauthentication of data. (ISO 8908)

Decipherment: Process of transforming cipher text into plain text - the reversal of acorresponding encipherment.

Declaration of conformity - Written statement by an interface module (IFM) providerclaiming that their production of a specific IFM type is in conformance with all relatedspecifications, as defined by EMVCo.

Digital Envelope - A cryptographic technique to encrypt data and send the encryptionkey along with the data. Generally, a symmetric algorithm is used to encrypt the dataand an asymmetric algorithm is used to encrypt the encryption key.

Digital Signature - An asymmetric cryptographic transformation of data that allows therecipient of the data to prove the origin and integrity of the data, and protect the senderand the recipient of the data against forgery by third parties, and the sender againstforgery by the recipient.

Electronic Commerce - The exchange of goods and services for payment between thecardholder and merchant when some or all of the transaction is performed via electroniccommunication.



Electronic Commerce Access Device - The combination of hardware and softwarerequired to interact with the cardholder, the ICC, and an electronic commerce system inorder 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., MasterCardInternational Incorporated, and Visa International Service Association for including, butnot limited to, smart card interoperability specifications and associated type approvalprocedures.

EMVCo test authority - The entity responsible for the type approval process.

Encipherment - The reversible transformation of data by a cryptographic algorithm toproduce 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 conformancestatement (ICS), this document describes the setup and handling of the system undertest (SUT) before and during the type approval tests, and describes the environmentalconditions and maximum rating the interface module (IFM) is designed for. The IFMprovider in cooperation with the testing laboratory defines this document.

Financial Transaction - The act between a cardholder and a merchant or acquirer thatresults in the exchange of goods or services against payment.

Function - A process accomplished by one or more commands and resultant actionsthat are used to perform all or part of a transaction.

Guardtime - The minimum time between the trailing edge of the parity bit of a characterand 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 thisoutput.

� It is computationally infeasible to find for a given input a second input that maps tothe same output.

Additionally, if the hash function is required to be collision-resistant, it must also satisfythe following property:

� It is computationally infeasible to find any two distinct inputs that map to the sameoutput.



Hash Result - The string of bits that is the output of a hash function.

Implementation conformance statement (ICS) - A form completed by the interfacemodule (IFM) provider. The written statement lists all optional functions as specified inthe reference specification implemented in the interface module (IFM). It includes theidentification description and external operating conditions (EOC) of the IFM.

Implementation under test (IUT) - A virtual or abstract device, implementing the EMVspecification, to be submitted for testing (a view of the interface module (IFM) isattached to the design).

Inactive - The supply voltage (VCC) and other signals to the ICC are in the inactivestate 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 beinstalled.

Integrated Circuit(s) - Electronic component(s) designed to perform processing and/ormemory functions.

Integrated Circuit(s) Card - A card into which one or more integrated circuits areinserted to perform processing and memory functions.

Integrated Circuit Module - The sub-assembly embedded into the ICC comprising theIC, the IC carrier, bonding wires, and contacts.

Interface Device - That part of a terminal into which the ICC is inserted, including suchmechanical and electrical devices that may be considered part of it.

Interface Module - A virtual or abstract device attached to a type productionconfiguration implemented as a physical device included in a terminal.

Interoperability - The ability of the software and hardware from different interfacemodule (IFM) providers to work together.

Issuer - A financial institution that supports issuing payment card products toindividuals.

Key - A sequence of symbols that controls the operation of a cryptographictransformation.

Key Activation: The process of beginning to use a key at the Certification Authority forthe production of public key certificates.

Key Expiry Date: The date after which a signature made with a particular key is nolonger 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.



Key Installation Deadline: The date by which all terminals must be able to verify issuercertificates based on this key, and the earliest date that cards may be issued thatcontain issuer certificates based on this key.

Key Introduction: The process of generating, distributing, and beginning use of a keypair.

Key Life Cycle: All phases of key management, from planning and generation, throughrevocation, destruction, and archiving.

Key Replacement: The simultaneous revocation of a key and introduction of a key toreplaced the revoked one.

Key Revocation: The key management process of withdrawing a key from service anddealing 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 shouldcontain certificates signed by this key, and therefore the date after which this key can bedeleted from terminals. For a planned revocation the Key Revocation Date is the sameas 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 isperforming type approval tests in conformance to the common rules, as defined byEMVCo.

Letter of approval - Written statement that documents the decision of the EMVCo TestAuthority that a specified product type has demonstrated sufficient conformance to theEMV specification.

Level 1 Test - The execution of a defined set of electrical, mechanical, andcommunication 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 improvedcryptanalytic techniques, increases in computing power, or combination of the two.

Lower tester - The integrated circuit card (ICC) simulator going to allow theimplementation 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 bemaintained.

Major modification - Technical change of an interface module (IFM) or its functionalitythat implies that the IFM provider can no longer guarantee conformance of the modified



IFM with the requirements of Part 1 of the EMV Integrated Circuit Card Specification forPayment Systems.

Merchant - A seller of goods, services, and/or information who accepts payment forthem electronically, and may provide selling services and/or electronic delivery of itemsfor sale (e.g., information).

Merchant Server - A system that interacts with the Cardholder System for electronicpayments. The Merchant Server also interacts with the Acquirer using the paymentprotocol to receive authorization and capture services for electronic paymenttransactions.

Merchant System - A system that interfaces with the cardholder (or ECAD) to offergoods and services in return for electronic payment and interfaces with the acquirersystem to process electronic commerce transactions.

Message - A string of bytes sent by the terminal to the card or vice versa, excludingtransmission-control characters.

Message Authentication Code - A symmetric cryptographic transformation of data thatprotects 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 functionalitythat does not impact the functionality of that IFM with respect to the requirements of Part1 of the Integrated Circuit Card Specification for Payment Systems and theimplementation conformance statement (ICS).

Network - A collection of communication and information processing systems that maybe 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 theICC when a payment system application conforming to this specification has beenselected, or when a directory definition file (DDF) used for payment system applicationpurposes has been selected.

Physical Compromise: The compromise of a key resulting from the fact that it has notbeen securely guarded, or a hardware security module has been stole or accessed byunauthorised persons.



Plaintext - Unenciphered information.

Planned Revocation: A key revocation performed as scheduled by the published keyexpiry date.

Potential Compromise: A condition where cryptanalytic techniques and/or computingpower has advanced to the point that compromise of a key of a certain length is feasibleor even likely.

Primary Account Number (PAN) - The assigned number that identifies the card issuerand cardholder. This account number is composed of an issuer identification number, anindividual account number identification, and an accompanying check digit, as definedby ISO 7812-1985.

Private Key - That key of an entity’s asymmetric key pair that should only be used bythat entity. In the case of a digital signature scheme, the private key defines thesignature function.

Proficiency - Ability of a testing laboratory to perform the specified tests in an exact andreproducible 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 theterminal, represented in this specification by T=0 (character protocol) and T=1 (blockprotocol).

Prototype - Implementation of a design for evaluation purposes but not for typeapproval.

Public Key - That key of an entity’s asymmetric key pair that can be made public. In thecase of a digital signature scheme, the public key defines the verification function.

Public Key Certificate - The public key information of an entity signed by thecertification authority and thereby rendered unforgeable.

Quality assurance - For purpose of this specification, all activities targeted atmaximizing the level of confidence that the quality of a product is constant anddemonstrated throughout volume production.

Quality system - An organization implementing quality procedures describing theoperations performed by its people in order to achieve its activity with the correct level ofquality.

Redundancy - Any information that is known and can be checked.

Reference specification - A set of documents defining the requirements to which theinterface module (IFM) shall comply. The reference specification consists of the currentEMV Integrated Circuit Card Specification for Payment Systems and any additionaldocumentation required to proceed with type approval.



Registration Authority An independent third-party organization that process paymentcard applications for multiple payment card brands and forwards applications to theappropriate financial institutions.

Response - A message returned by the ICC to the terminal after the processing of acommand message received by the ICC.

RSA Failure: An advance in mathematics, cryptanalysis or technology that renders RSAkey technology ineffective, regardless of key or key size.

Sample - Terminal, including the implementation under test (IUT), picked out ofproduction for testing.

Secret Key - A key used with symmetric cryptographic techniques and usable only by aset of specified entities.

Script - A command or a string of commands transmitted by the issuer to the terminalfor the purpose of being sent serially to the ICC as commands.

Secure Socket Layer (SSL) - a standard (developed by Netscape CommunicationsCompany) that encrypts data between a Web browser and a Web server. SSL does notspecify 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, usingterminals 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 operationsuch as undershoot/overshoot, electrical noise, ripple, spikes, crosstalk, etc. Randomperturbations introduced from external sources are beyond the scope of thespecification.

State H - Voltage high on a signal line. May indicate a logic one or logic zero dependingon the logic convention used with the ICC.

State L - Voltage low on a signal line. May indicate a logic one or logic zero dependingon the logic convention used with the ICC.

Statement of readiness - Part of the implementation conformance statement (ICS); it isa declaration by the interface module (IFM) provider that the IFM type conforms to theEMV specifications.

Statement of specification acceptance- Written statement from the interface module(IFM) provider that states the IFM provider accepts all related specifications as definedby EMVCo.



Suspected Compromise: A condition where information from system monitoringindicates malfunction which could be caused by key compromise, but which has notbeen confirmed as such.

Symmetric Cryptographic Technique - A cryptographic technique that uses the samesecret key for both the originators and recipient’s transformation. Without knowledge ofthe secret key, it is computationally infeasible to compute either the originator’s or therecipient’s transformation.

System integrator - The entity that integrates interface modules (IFMs) and devicescontaining IFMs into a system for use by a service provider.

System under test (SUT) - System, module, part, or component actually tested or to betested (either a part of the terminal or the entire terminal) including the implementationunder 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 ofdata objects.

Terminal - The device used in conjunction with the ICC at the point of transaction toperform a financial transaction. It incorporates the interface device and may also includeother components and interfaces such as host communications.

Terminal application layer (TAL) - The part of the terminal that initiates a command. Itsends 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 orprocess 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 thepurpose of type approval tests.

Type Approval - Acknowledgment by EMVCo that the specified product hasdemonstrated sufficient conformance to the EMVCo ICC specifications for its statedpurpose.

Type Approval documentation - Full set of documents and procedures issued byEMVCo to perform the type approval process.

Type Approval process - The processes followed to test a product type for compliancewith a certain specification.

Type Approval test - The execution of a defined set of tests against requirementsdescribed in a specification to determine compliance with that specification.

Type approval test report - The result of type approval testing on a product.



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 ICCwhile the clock (CLK) and supply voltage (VCC) lines are maintained in their activestate.



Command Syntax The intent of the test cases in this Section is to verify that the commands are in accordance withEMV 2000 Integrated Circuit Card Specifications for Payment Systems - Part I - Book 3 -Application Specification. While the application will be utilized to perform command syntaxchecking, functionality testing will not be specifically checked, but will be tested in other sectionsas specified.



2CS.001.00 Mandatory Command Set

Test No. 2CS.001.00

Objective: To ensure that all terminals issue the basic mandatory commands in the correctformat 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 CommandData Field

2RA.045.0 - Book 3 Section 2.5.8.2 - Syntax of GET PROCESSINGOPTIONS Command

2RA.058.5 - Book 3 Section 2.5.11.3 & Book 1 Section 7.2.3 - Syntax ofREAD 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: P2parameter

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 EMVtransaction:� Application Selection� Initiate Application Processing� Read Application Data� Terminal Action Analysis� Completion.

Pass Criteria: � 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



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)



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 andissued at the expected times during the transaction flow.

Reference: 2RA.061.0 - Book 1Section 7.3.2 - Syntax of SELECT Select command: P2parameter

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'

� 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 EMVtransaction:

� 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



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



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 FileLocators.




2CS.003.00 Internal Authenticate Command

Test No. 2CS.003.00

Objective: To ensure that if the terminal supports Dynamic Data Authentication, the internalauthenticate command is properly issued.

Reference: 2RA.053.0 - Book 3 Section 2.5.9.2 - Syntax of INTERNALAUTHENTICATION command

2RA.054.0 - Book 3 Section 2.5.9.3 - Syntax of INTERNALAUTHENTICATION 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'



� Application Selection� Initiate Application Processing� Read Application Data� Data Authentication� Terminal Action Analysis� Completion.

Pass Criteria: � 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

Application Data but prior to 1st Gen AC command� Each command shall contain the correct syntax and be issued at the






- 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 FileLocators.

- Internal Authenticate: Mandatory if terminal supports Dynamic DataAuthentication

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)




2CS.004.00 Verify Command

Test No. 2CS.004.00

Objective: To ensure that terminal supporting Cardholder verification form, Plaintext PINverified by ICC, issues the Verify Command in the correct format and is issued atthe expected time during the transaction flow. If the terminal supports Get Data forPIN 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: P2parameter

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'



� Application Selection� Initiate Application Processing� Read Application Data� Cardholder Verification� Terminal Action Analysis� Completion.

Pass Criteria: � 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

to 1st GEN AC.� Each command shall contain the correct syntax and be issued at the






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




2CS.005.00 Get Challenge

Test No. 2CS.005.00

Objective: To ensure to the terminal issues the Get Challenge and Verify command in thecorrect format and issues them at the expected times during the transaction flow ifthe terminal supports Cardholder verification form, Enciphered PIN verified by ICC.If the terminal supports Get Data command for PIN Try counter, it shall be issuedprior to the Verify command.

Reference: 2RA.072.0 - Book 3 Section 2.5.6.2 - Syntax of GET CHALLENGEcommand

2RA.072.5 - Book 3 Section 2.5.6.3 - Syntax of GET CHALLENGEcommand Data Field

2RA.067.0 - Book 3 Section 2.5.12.2 - Syntax of VERIFY command: P2parameter

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'



� Application Selection� Initiate Application Processing� Read Application Data� Cardholder Verification� Terminal Action Analysis� Completion.

Pass Criteria: � 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






- 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 FileLocators.

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




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 RiskManagement, the terminal shall issue the Get Data command in the correct formatand 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 DataField

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'

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


� Application Selection� Initiate Application Processing� Read Application Data� Terminal Risk Management� Terminal Action Analysis� Completion.

Pass Criteria: � 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 ReadApplication Data but prior to 1st GEN AC.

� Each command shall contain the correct syntax and be issued at theappropriate 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 FileLocators.

- 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




2CS.007.00 External Authenticate

Test No. 2CS.007.00

Objective: To ensure that a terminal with online capability can issue the External Authenticatecommand after the first Generate AC but prior to second Generate AC. Thecommand is in the correct format and issued at the expected times during thetransaction flow.

Reference: 2RA.036.0 - Book 3 Section 2.5.4.2 - Syntax of EXTERNALAUTHENTICATE command

2RA.037.0 - Book 3 Section 2.5.4.3 - Syntax of EXTERNALAUTHENTICATE 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� 1st 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'



� Application Selection� Initiate Application Processing� Read Application Data� Terminal Action Analysis� Online Processing� Issuer Authentication� Completion.

Pass Criteria: � 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






- 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 FileLocators.

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



ICC Specification for Payment System, TestCase Description

Book 3 Part 1 - Data Element and Commands

2CA.001.03 Data elements Storage

Test No. 2CA.001.03

Objective: To ensure that the retrieved values fields of the data elements are stored inthe 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 beapproved

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 captureshall be in accordance with values sent back by the LT



2CA.001.00 Coding and Allocation of Tags

Test No. 2CA.001.00

Objective: To ensure that the terminal complies with the Data Object coding andallocation 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 Allocationof Tags

Conditions: LT is such as all types of Data Objects are exchanged during thetransaction:

� 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 withISO/IEC 7816-6 coding


Pass Criteria: � Data Object received by the Terminal shall be interpreted correctly



2CA.001.04 Coding of Length in TLV

Test No. 2CA.001.04

Objective: To ensure that the terminal is capable of correctly interpreting TLV dataobjects with a length field coded ‘00’ as defined in ISO/IEC 7816. A dataelement 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'


Pass Criteria: � The terminal shall treat this data as not present and completetransaction

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 intorecords .

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 (andAFL is in accordance) (for instance Track2 Equivalent Data can belocated in file with any SFI value)

� Data objects of LT are ordered differently within records (for instancemandatory data object Expiration Date, PAN, CDOL1 and CDOL2 canbe ordered differently)

Procedure: Read Application Data phase is performed with the LT for all conditionsabove

Pass Criteria: � The terminal shall perform Read Application Data phase correctly andprocess 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)



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 anyvalue 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 forthe 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 SFItested

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 performedwith LT

Pass Criteria: � The terminal shall return a GET PROCESSING OPTION command tothe LT with PDOL field correctly filled



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 List1 (CDOL1)

Conditions: � Application data in LT contains a valid CDOL1


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT withCDOL1 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 List2 (CDOL2)

Conditions: � Application data in LT contains a valid CDOL2.

� Terminal parameters is set so that transaction is performed on-line


Pass Criteria: � The terminal shall return a 2nd GENERATE AC command to the LT withCDOL2 field correctly filled



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


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT with TCHash 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


Pass Criteria: � The terminal shall return an INTERNAL AUTH command to the LT withDDOL field correctly filled



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 isunknown to the terminal, the IUT provides a data element with the lengthspecified 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 theterminal.

Procedure: Application in LT is selected and transaction is performed with LT (inparticular the DOL processing).

Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object filled with hexadecimal zeroes (portion has the samelength 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 DOLrepresents a constructed data object, the IUT provides a data element withthe length specified and a value of all hexadecimal zeroes.

Reference: 2RA.008.1 - Book 3 Section 1.4 - Processing DOLs: constructed tag


� The DOL contains a tag representing a constructed Data Object.





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 theIUT but represents optional static data absent from the ICC, the portion ofthe command field corresponding is filled with hexadecimal zeroes

Reference: 2RA.009.0 - Book 3 Section 1.4 - Processing DOLs: data absent from ICC


� The DOL contains a Data Object representing static data that is absentfrom the ICC



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 thanthe length of the actual data object, leftmost bytes of the data element aretruncated if the data object has numeric format.

Reference: 2RA.010.0 - Book 3 Section 1.4 - Processing DOLs: shorter data objectlength, numeric format


� The DOL contains a data object which has numeric format and a lengthshorter than actual Data Object Length


Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object correctly truncated (portion has the same length as theData Object in DOL).



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 thanthe length of the actual data object, rightmost bytes of the data element aretruncated if the data object has any other format than numeric.

Reference: 2RA.010.1 - Book 3 Section 1.4 - Processing DOLs: shorter data objectlength, other format


� The DOL contains a data object which has a format other than numericand a length shorter than actual Data Object Length


Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object correctly truncated (portion has the same length as theData Object in DOL).



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 greaterthan the length of the actual data object, the actual data is padded withleading hexadecimal zeroes if the data object has numeric format.

Reference: 2RA.011.0 - Book 3 Section 1.4 - Processing DOLs: longer data objectlength, numeric format


� The DOL contains a data object which has numeric format and a lengthlonger than actual Data Object Length


Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object correctly padded with leading hexadecimal zeroes(portion has the same length as the Data Object in DOL).



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 greaterthan the length of the actual data object, the actual data is padded withtrailing hexadecimal FF’s if the data has a compressed numeric format.

Reference: 2RA.011.1 - Book 3 Section 1.4 - Processing DOLs: longer data objectlength, compressed numeric format


� The DOL contains a data object which has compressed numeric formatand a length longer than actual Data Object Length


Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object correctly padded with trailing hexadecimal FF’s (portionhas the same length as the Data Object in DOL).



2CA.020.00 Processing DOLs: longer data object length, otherformat

Test No. 2CA.020.00

Objective: To verify that whenever the length specified in the DOL entry is greaterthan the length of the actual data object, the actual data is padded withtrailing hexadecimal zeroes for any other format than numeric orcompressed numeric.

Reference: 2RA.011.2 - Book 3 Section 1.4 - Processing DOLs: longer data objectlength, other format


� The DOL contains a data object which has a format other than numericor compressed numeric and a length longer than actual Data ObjectLength


Pass Criteria: � The LT shall receive the DOL with portion of the DOL field representingthe Data Object correctly padded with trailing hexadecimal zeroes(portion has the same length as the Data Object in DOL).



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 theIUT but is not applicable to the current transaction, the portion of thecommand field corresponding is filled with hexadecimal zeroes

Reference: 2RA.012.0 - Book 3 Section 1.4 - Processing DOLs: data not applicable


� The DOL contains a data object which represents data that is notapplicable to the current transaction





2CA.025.00 Normal Processing for EXTERNALAUTHENTICATE

Test No. 2CA.025.00

Objective: To ensure that the terminal accepts a valid status ‘90 00’ in response toEXTERNAL AUTHENTICATE command and understands it as normalprocessing

Reference: 2RA.018.0 - Book 3 Section 2.3.5 - Normal Processing for ExternalAuthenticate

Conditions: � Terminal and LT parameters are set so that transaction is performed on-line.

� AIP of LT is set so that Issuer Authentication is supported.

� Issuer Authentication Data is sent back to the terminal in the emulatedresponse from Issuer.

� LT shall return status ‘90 00’ in response to EXTERNALAUTHENTICATE command.

� CDOL2 requests TVR and TSI

Procedure: Application in LT is selected and transaction is processed with LT (inparticular 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.



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 toEXTERNAL AUTHENTICATE command and understands it as failedprocessing

Reference: 2RA.018.1 - Book 3 Section 4.1 - Failed processing for ExternalAuthenticate (1)

Conditions: � Terminal and LT parameters are set so that transaction is performed on-line.

� AIP of LT is set so that Issuer Authentication is supported.

� Issuer Authentication Data is sent back to the terminal in the emulatedresponse from Issuer.

� LT returns status ‘63 00’ in response to EXTERNAL AUTHENTICATE


Procedure: Application in LT is selected and transaction is processed with LT (inparticular on-line processing and Issuer Authentication processing).


� TVR byte 5, bit 7 = ‘1’ ie Issuer Authentication Unsuccessful

� TSI byte 1, bit 5=’1’ ie Issuer authentication was performed



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 toGENERATE 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 validresponse

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 toGET 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 avalid response

� CVM is 'Enciphered offline PIN verification, always'

� PIN entered is good

� CDOL1 requests TSI and TVR



� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification was successful

� TSI byte 1, bit 7 =‘1’ Cardholder Verification was performed



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 toGET 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 andLOATC retrieval).

� LT returns status ‘90 00’ in response to GET DATA as well as a validresponse




� TVR byte 1, bit 6 = ‘0’ ie ICC Data not missing



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' inresponse to GET DATA command and understands it as failed processingwhen 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


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



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' inresponse to GET DATA command and understands it as failed processingand 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.




� The terminal performs PIN processing



2CA.030.00 Normal Processing for GET PROCESSINGOPTIONS

Test No. 2CA.030.00

Objective: To ensure that the terminal accepts a valid status ‘90 00’ in response toGET PROCESSING OPTIONS command and understands it as normalprocessing

Reference: 2RA.022.0 - Book 3 Section 2.3.5 - Normal Processing for Get ProcessingOptions

Conditions: � LT returns status ‘90 00’ in response to GET PROCESSING OPTIONSas well as a valid response



2CA.030.05 Failed Processing for GET PROCESSINGOPTIONS

Test No. 2CA.030.05

Objective: To ensure that the terminal accepts a failed status ‘6985’ in response toGET PROCESSING OPTIONS command and understands it as failedprocessing.

Reference: 2RA.022.5 - Book 3 Section 2.3.5 & Section 6.1 - Failed Processing for GetProcessing Options

Conditions: � The LT and the terminal have two mutually supported applications

� LT returns status ‘6985’ in response to GET PROCESSING OPTIONSof the first selected application

Procedure: The first application in the candidate list in selected, then removed and theterminal initiate the selection of the second mutually supported application.

Pass Criteria: � In response to the status words ‘6985’, the terminal shall terminateprocessing the current application and

� return to the application selection function to select another application



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 toINTERNAL AUTHENTICATE command and understands it as normalprocessing

Reference: 2RA.023.0 - Book 3 Section 2.3.5 - Normal Processing for InternalAuthenticate

Conditions: � LT and terminal support DDA. LT returns status ‘90 00’ in response toINTERNAL AUTHENTICATE as well as a valid response

� CDOL1 request TVR and TSI

Procedure: Application in LT is selected and transaction is processed with LT (inparticular Dynamic Data Authentication).


� 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 toREAD 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 avalid response

Procedure: Application in LT is selected and transaction is processed with LT (inparticular the Read Application Data phase).




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 toREAD 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 recordnumber 1 in application selection using PSE

Procedure: The first application in the candidate list in selected, then removed and theterminal initiate the selection of the second mutually supported application.

Pass Criteria: � In response to the status words ‘6A83’, the terminal shall terminate PSEprocessing 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 toSELECT 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 validresponse





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 toVERIFY 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 ‘9000’ in response to VERIFY.


Procedure: Application in LT is selected and transaction is processed with LT (inparticular Cardholder verification).


� 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



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 VERIFYcommand 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 EncipheredPIN 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 9bits 6-1 = ‘000011’)

or 'Enciphered PIN verification performed by ICC and signature' (byte9 bits 6-1 = ‘000101’)


� The operator enters a wrong PIN

� LT returns status ‘’63C2" then "63C1" then "63C0" in response to theVerify 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 stopssending verify commands.

� TVR byte 3, bit 6=’1’ ie PIN Try Limited exceeded





Test No. 2CA.034.03

Objective: To ensure that the terminal accepts a failed status ‘69 83’ in response toVERIFY command and understands it as failed processing.





or 'Plaintext PIN verification performed by ICC and signature' (byte 9 bits6-1 = ‘000011’)

or 'Enciphered PIN verification performed by ICC and signature' (byte 9bits 6-1 = ‘000101’)


� LT returns status ‘’6983" in response to the Verify Command




� TVR byte 3, bit 6 = ‘1’ ie PIN Try limit exceeded




Test No. 2CA.034.04

Objective: To ensure that the terminal accepts a failed status ‘69 84’ in response toVERIFY command and understands it as failed processing.





or 'Plaintext PIN verification performed by ICC and signature' (byte 9 bits6-1 = ‘000011’)

or 'Enciphered PIN verification performed by ICC and signature' (byte 9bits 6-1 = ‘000101’)


� LT returns status ‘’6984" in response to the Verify Command







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 toGENERATE 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 toGENERATE AC


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 GETCHALLENGE command is different from ‘90 00’.

Reference: 2RA.027.2 - Book 3 Section 2.3.5 - Status Word Processing: GetChallenge

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'


Pass Criteria: � The terminal shall terminate processing of transaction



2CA.037.00 Status Word Processing for GET PROCESSINGOPTIONS

Test No. 2CA.037.00

Objective: To ensure that the terminal rejects transaction if status in response to GETPROCESSING OPTIONS command is different from ‘90 00’ and ‘69 85’.

Reference: 2RA.027.4 - Book 3 Section 2.3.5 - Status Word Processing: GetProcessing Options

Conditions: � LT returns several status values different from ‘90 00’ and ‘69 85’ inresponse to GET PROCESSING OPTIONS.

Procedure: Application in LT is selected and transaction is started with LT.


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 toREAD RECORD command sent outside application selection is differentfrom ‘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’ inresponse to READ RECORD during the Read Application Data phase.

Procedure: Application in LT is selected and transaction is processed with LT up to theRead Application Data phase.




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 toVERIFY 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.



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 theterminal 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 InterchangeProfile, Application Usage Control, CVM list, Application PriorityIndicator, Issuer Action Code, Terminal Action Code)


Pass Criteria: � The terminal shall not verify RFU bits and complete transaction



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 ACreturned Data field encoded according to format 1 syntax and in particularthe order of the value field of Data Object included in the returned Datafield.

Reference: 2RA.040.0 - Book 3 Section 2.5.5.4 - Syntax of GENERATE AC returnedData Field (Format 1)

Conditions: � Response to GENERATE AC includes Issuer Application Data and shallbe encoded with format 1 (Template 80)


Pass Criteria: � The terminal shall accept the card and interprete correctly the format 1syntax.

� 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 inauthorization or financial requests or batch data capture shall be inaccordance with values sent back by the LT



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 ACreturned Data field encoded according to format 2 syntax.

Reference: 2RA.041.0 - Book 3 Section 2.5.5.4 - Syntax of GENERATE AC returnedData Field (Format 2)

Conditions: � Response to GENERATE AC includes Issuer Application Data and shallbe encoded with format 2 (Template 77)


Pass Criteria: � The terminal shall accept the card and interprete correctly the format 2syntax.

� The terminal shall run the transaction to completion according to theLT’s response to the GENERATE AC command.

2CA.056.00 Proprietary Data Object transmitted in Responseto GENERATE AC: Format 2

Test No. 2CA.056.00

Objective: To ensure that the terminal ignores proprietary data object contained in theresponse 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 inResponse to GENERATE AC: Format 2 (implied)

Conditions: � Response to GENERATE AC includes Proprietary Data Object and shallbe encoded with format 2 (Template 77)


Pass Criteria: � The terminal shall accept the card and ignore the format 2 proprietarydata object in the response to the GENERATE AC command.

� The terminal shall process the transaction until the end.



2CA.057.00 Cryptogram Information Data

Test No. 2CA.057.00

Objective: To ensure that the terminal accepts the presence of a valid CryptogramInformation 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


Pass Criteria: � The terminal shall accept the card and process the transaction until theend.

� The terminal shall act in the appropriate manner for the returnedCryptogram Information Data (i.e. Terminal requests TC and ICC returnsTC, 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 ofApplication Transaction Counter in response to the GENERATE ACcommand.

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



� The terminal will return the correct value of the ATC during SecondGENERATE AC as returned by the LT during First GENERATE AC.



2CA.059.00 Application Cryptogram

Test No. 2CA.059.00

Objective: To ensure that the terminal accepts the presence of a valid format ofApplication 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




� The terminal will return the correct value of the Application Cryptogramduring Second GENERATE AC as returned by the LT during FirstGENERATE AC



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 IssuerApplication 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




� The terminal will return the correct value of the Issuer Application Dataduring Second GENERATE AC as returned by the LT during FirstGENERATE 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 ACcommand 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 untilcompletion

Pass Criteria: � The terminal shall decline the transaction



2CA.062.00 Cryptogram Information Data: TC

Test No. 2CA.062.00

Objective: To verify that the terminal interprets correctly answer to a GENERATE ACcommand 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 GENERATEAC


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 ACcommand 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 firstGENERATE AC


Pass Criteria: � The terminal shall complete the transaction on line



2CA.064.00 Cryptogram Information Data: AAR

Test No. 2CA.064.00

Objective: To verify that the terminal interprets correctly answer to a GENERATE ACcommand 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


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 ACcommand requiring an Advice.

Reference: 2RA.042.8 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: Advicerequired

Conditions: � The LT requires an Advice in response to the first GENERATE AC.

� Terminal supports Advices


Pass Criteria: � The terminal shall create and transmit an advice.



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 ACcommand requiring an Advice and indicating a Service not allowed.

Reference: 2RA.042.9 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: ServiceNot allowed

Conditions: � The LT requests an AAC and requires an Advice in response to the firstGENERATE AC.

� Reason indicated by LT is service not allowed.



Pass Criteria: � The terminal shall either transmit an on line advice or create an offlineadvice.

� Reason for decline included in Advice shall be service not allowed



2CA.067.00 Cryptogram Information Data: PIN try limitexceeded

Test No. 2CA.067.00

Objective: To verify that the terminal interprets correctly answer to a GENERATE ACcommand requiring an Advice and indicating a PIN try limit exceeded.

Reference: 2RA.042.10 - Book 3 Section 2.5.5.4 - Cryptogram Information Data: PINtry limit exceeded

Conditions: � The LT requests an AAC and requires an Advice in response to the firstGENERATE AC.

� Reason indicated by LT is PIN try limit exceeded.



Pass Criteria: � The terminal shall either transmit an on line advice or create an offlineadvice.

� Reason for decline included in Advice shall be PIN try limit exceeded



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 returnedData field when ATC is requested

Reference: 2RA.044.0 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned DataField (ATC)


� LT requesting terminal to perform risk management (AIP byte 1 bit 4 =1).

� LT contains Lower and Upper consecutive offline limits (for ATCretrieval).

� LT returns status ‘90 00’ in response to GET DATA as well as a validresponse (ATC)

� CDOL1 Requests TVR and TSI


Pass Criteria: � The terminal shall accept the card and process the transaction until theend

� TVR byte 1, bit 6 = ‘0’ ie ICC Data not Missing

� TSI Byte 1, bit 4=1 ie Terminal risk Management was performed



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 returnedData field when LOATC is requested

Reference: 2RA.044.1 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned DataField (LOATC)


� LT requesting terminal to perform risk management (AIP byte 1 bit 4 =1).

� LT contains Lower and Upper consecutive offline limits (for LOATCretrieval).

� LT returns status ‘90 00’ in response to GET DATA as well as a validresponse (LOATC)



Pass Criteria: � The terminal shall accept the card and process the transaction until theend

� TVR byte 1, bit 6 = ‘0’ ie ICC Data not Missing

� TSI Byte 1, bit 4=1 ie Terminal risk Management was performed



2CA.072.00 Syntax of GET DATA returned Data Field (PIN trylimit)

Test No. 2CA.072.00

Objective: To ensure that the terminal is able to recognize the GET DATA returnedData field when PIN try limit is requested

Reference: 2RA.044.2 - Book 3 Section 2.5.7.1 - Syntax of GET DATA returned DataField (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 validresponse (PIN try Counter)





� TSI Byte 1, bit 7=1 ie, Cardholder verification was performed



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 OPTIONScommand with a Processing Options Data Object List (PDOL) when PDOLdata 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 PROCESSINGOPTIONS Data Field (PDOL)

Conditions: � PDOL is returned in the FCI of the selected ADF


Pass Criteria: � The LT shall receive a GET PROCESSING OPTIONS data field(associated to the GET PROCESSING OPTIONS command field) withthe correct syntax: data object containing value fields of Data Objectrequested 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 OPTIONScommand without a Processing Options Data Object List (PDOL) when thePDOL 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 DataField (no PDOL)

Conditions: � PDOL is not returned in the FCI of the selected ADF


Pass Criteria: � The LT shall receive a GET PROCESSING OPTIONS data field(associated to the GET PROCESSING OPTIONS command field) withthe correct syntax: data object with length = 0 and Tag ‘83’



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 OPTIONScommand without a Processing Options Data Object List (PDOL) when thePDOL 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 PROCESSINGOPTIONS Data Field: PDOL empty (implied)

Conditions: � PDOL is returned in the FCI of the selected ADF and is empty


Pass Criteria: � The LT shall receive a GET PROCESSING OPTIONS data field(associated to the GET PROCESSING OPTIONS command field) withthe correct syntax: data object with length = 0 and Tag ‘83’



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 PROCESSINGOPTIONS returned Data field encoded according to format 1.

Reference: 2RA.049.0 - Book 3 Section 2.5.8.3 - Syntax of GET PROCESSINGOPTIONS returned Data Field: Format 1

Conditions: � Response to GET PROCESSING OPTIONS contains valid AIP andAFL encoded with format 1 (Template 80)

� CDOL 1 requests AIP



� Value of AIP in GENERATE AC command shall be in accordance withthe value sent back by the LT.

� LT shall receive READ RECORD commands in accordance to AFL



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 PROCESSINGOPTIONS returned Data field encoded according to format 2.

Reference: 2RA.050.0 - Book 3 Section 2.5.8.4 - Syntax of GET PROCESSINGOPTIONS returned Data Field: Format 2

Conditions: � Response to GET PROCESSING OPTIONS contains valid AIP andAFL encoded with format 2 (Template 77)

� CDOL 1 requests AIP



� Value of AIP in GENERATE AC command shall be in accordance withthe value sent back by the LT.

� LT shall receive READ RECORD commands in accordance to AFL



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 theINTERNAL AUTHENTICATE command which initiates the computation ofthe Signed Dynamic Application Data by the card.

Reference: 2RA.053.0 - Book 3 Section 2.5.9.2 - Syntax of INTERNALAUTHENTICATE command

Conditions: � Terminal and LT support DDA

� LT contains DDOL and all data needed for Dynamic Data Authenticationas defined in Book 2


Pass Criteria: � The LT shall receive INTERNAL AUTHENTICATE command with thecorrect syntax: 00 88 00 00 xx

2CA.082.00 Syntax of INTERNAL AUTHENTICATE Data Field

Test No. 2CA.082.00

Objective: To ensure that the terminal issues an INTERNAL AUTHENTICATEcommand with a Dynamic Data Authentication Data Object List (DDOL)

Reference: 2RA.054.0 - Book 3 Section 2.5.9.2 - Syntax of INTERNALAUTHENTICATE Data Field




Pass Criteria: � The LT shall receive an INTERNAL AUTHENTICATE data field(associated to the INTERNAL AUTHENTICATE command field) with thecorrect syntax: data object containing value fields of Data Objectrequested in DDOL



2CA.083.00 Syntax of INTERNAL AUTHENTICATE returnedData Field: Format 1

Test No. 2CA.083.00

Objective: To ensure that the terminal is able to recognize the INTERNALAUTHENTICATE returned Data field encoded according to format 1

Reference: 2RA.055.0 - Book 3 Section 2.5.9.4 - Syntax of INTERNALAUTHENTICATE returned Data Field: Format 1



� LT response to INTERNAL AUTHENTICATE shall be a correctcryptogram encoded with format 1 (template 80)




� TVR byte 1, bit 4 = ‘0’ ie Dynamic Data Authentication succeeded



2CA.084.00 Syntax of INTERNAL AUTHENTICATE returnedData Field: Format 2

Test No. 2CA.084.00

Objective: To ensure that the terminal is able to recognize the INTERNALAUTHENTICATE returned Data field encoded according to format 2

Reference: 2RA.056.0 - Book 3 Section 2.5.9.4 - Syntax of INTERNALAUTHENTICATE Internal Authenticate returned Data Field: Format 2



� LT response to INTERNAL AUTHENTICATE is a correct cryptogramencoded with format 2 (template 77)




� TVR byte 1, bit 4 = ‘0’ ie Dynamic Data Authentication succeeded



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 READRECORD command that sends transaction-related data to the ICC, whichcomputes and returns a cryptogram

Reference: 2RA.058.0 - Book 3 Section 2.5.11.2 - Syntax of READ RECORDcommand

Conditions: � AFL is not empty


Pass Criteria: � The LT shall receive an READ RECORD command with the correctsyntax: 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 RECORDreturned Data field.

Reference: 2RA.059.0 - Book 3 Section 2.5.11.4 & Book 1 Section 7.2.4 - Syntax ofREAD 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.



� Values of PAN And Application Expiration date shall be in accordanceof the value returned by the LT.



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 theSELECT data field

Reference: 2RA.062.0 - Book 1 Section 7.3.3 - Syntax of SELECT Data Field

Conditions: � No specific conditions


Pass Criteria: � The LT shall receive a SELECT data field (associated to the SELECTcommand 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 torecognize the SELECT PSE returned Data field.

Reference: 2RA.063.0 - Book 1 Section 7.3.4 - Syntax of SELECT PSE returned DataField

Conditions: � FCI of PSE contains mandatory and optional data fields

� Terminal supports selection with PSE



� LT shall received a READ RECORD command with SFI coded accordingto SFI returned in FCI



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 theabsence 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 DataField: optional data (implied)

Conditions: � FCI of PSE contains mandatory but no optional data fields




� The terminal shall either propose a choice of supported languages oruse the supported language if it supports only one




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 torecognize the SELECT DDF returned Data field.

Reference: 2RA.063.2 - Book 1 Section 7.3.4 - Syntax of SELECT DDF returned DataField

Conditions: � LT contains a DDF

� FCI of DDF contains mandatory and optional data fields




� LT shall received a READ RECORD command with SFI coded accordingto SFI returned in FCI of DDF



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 theabsence 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 DataField: optional data (implied)

Conditions: � FCI of DDF contains mandatory but no optional data fields




� LT shall received a READ RECORD command with SFI coded accordingto SFI returned in FCI of DDF



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 returnedData field.

Reference: 2RA.063.4 - Book 1 Section 7.3.4 - Syntax of SELECT ADF returned DataField

Conditions: � LT contains an ADF

� FCI of ADF contains mandatory and optional data fields



� Terminal shall send a GET PROCESSING OPTIONS command withPDOL 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 inthe SELECT ADF returned Data field.

Reference: 2RA.063.5 - Book 1 Section 7.3.4 - Syntax of SELECT ADF returned DataField: optional data


� FCI of ADF contains mandatory but no optional data fields





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 dataobjects in the SELECT returned Data field.

Reference: 2RA.064.0 - Book 1 Section 7.3.4 - Response to Proprietary Data in FCI


� FCI of ADF contains proprietary data fields



2CA.103.00 Syntax of VERIFY Data Field for option plaintextoffline PIN

Test No. 2CA.103.00

Objective: To ensure that the terminal issues a VERIFY command with a Plain TextOffline 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 foroption 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 allPIN length tested

Pass Criteria: � The LT shall receive a VERIFY data field (associated to the VERIFYcommand field) with the correct syntax as defined in Book 3 Section2.5.12.2



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 oftag 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 VERIFYcommand 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 CHALLENGEreturned Data field.

Reference: 2RA.073.0 - Book 3 Section 2.5.6.4 - Syntax of Get challenge returnedData Field

Conditions: � Terminal and LT support Offline enciphered PIN Verification.

� CVM is 'Offline enciphered PIN Verification, always'



� The LT shall receive a VERIFY command with Data field containing,once decrypted, unpredictable number sent back by LT



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 understandsPSE format and in particular recognize the FCI of the PSE and optionaldata 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.




2CB.004.00 Definition of a Record in Payment SystemsDirectory

Test No. 2CB.004.00

Objective: To ensure that if the terminal supports selection with PSE, it understandsthe format of records contained in the Directory file of PSE and in particularrecords with several entries.

Reference: 2RB.004.0 - Book 1 Section 8.2.3 - Definition of a Record in PaymentSystems Directory


� 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 supportedpriority hierarchies.

Pass Criteria: � The terminal shall accept the card

� LT shall receive a second READ RECORD command with SFI codedaccording to SFI returned in FCI of the SELECT PSE command.



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 ignoresunexpected Tags that would appear in directory entry and any data objectsnot encapsulated in an Application Template which appear in the directoryrecord.

Reference: 2RB.005.0 - Book 1 Section 8.2.3 - Definition of Directory Entry Format


� PSE contains a directory file with entries for ADF

� One record contains Tags that are not located in Template 61 andunexpected Tags (Tag that are not listed in Table 42 and 43 of Book 1Section 8.2.3)

Procedure: Application Selection with PSE process is performed for all supportedpriority hierarchies.


� LT shall receive a second READ RECORD command with SFI codedaccording to SFI returned in FCI of the SELECT PSE command.



2CB.006.00 Reading the Directory

Test No. 2CB.006.00

Objective: To ensure that if the terminal supports selection with PSE, it accepts anysupported value for the SFI of the directory file of a DDF.

Reference: 2RB.007.0 - Book 1 Section 8.2.4 - Reading the Directory


� 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 supportedvalues of SFI

Pass Criteria: � The LT shall receive a READ RECORD command for all values of SFI ofDDF tested

2CB.007.00 Terminal’s 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 - Terminal’s List of Supported Applications

Conditions: � LT does not support PSE selection in order to force the terminal to applyanother selection technique ( by using its list of AID’s ).

Procedure: Application Selection with AID is performed with LT

Pass Criteria: � The terminal generates SELECT command for each AID stored withinthe terminal.



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 ofwhich matching criteria to use and in particular that the terminal is able tosupport « AID match AID kept in terminal » criteria

Reference: 2RB.012.0 - Book 1 Section 8.3.1 - Matching AIDS: « same AID » criteriasupported

Conditions: � LT contains an application with AID matching AID kept in terminal

� Terminal supports « AID match AID kept in terminal » criteria for thisapplication

� A list is presented to the cardholder.

Procedure: Application Selection using list of AID is performed with LT


� Terminal shall indicate to cardholder which application can be selected



2CB.011.00 Matching AIDs: « AID beginning with TerminalAID » criteria supported

Test No. 2CB.011.00

Objective: To ensure that the terminal keeps for each application an indication ofwhich matching criteria to use and in particular that the terminal is able tosupport « AID beginning with terminal AID» criteria

Reference: 2RB.012.1 - Book 1 Section 8.3.1 - Matching AIDs: « AID beginning withTerminal AID » criteria supported

Conditions: � LT contains several applications. The beginning of the AID of theseapplications is identical and match the beginning of one of the AID keptin terminal

� Application have different priorities in the LT

� Terminal supports several AID but one of the supported AID has a valuematching the beginning of all AID in LT

� Terminal supports « AID beginning with terminal AID» criteria for thisAID


Procedure: Application Selection using list of AID is performed with LT

Pass Criteria: � The terminal shall accept the card .




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 aSELECT ‘1PAY.SYS.DDF01’ command

Reference: 2RB.013.0 - Book 1 Section 8.3.2 - Selection Using the Payment SystemsDirectory: SELECT PSE



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 terminatesthe transaction.

Reference: 2RB.014.0 - Book 1 Section 8.3.2 - Selection Using the Payment SystemsDirectory: Card Blocked or Command Not Supported


� LT returns ‘6A 81’ to SELECT PSE command


Pass Criteria: � The terminal shall terminate the transaction.



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 returnsstatus other than ‘90 00’ or ‘6A 81’ in response to the SELECT PSEcommand, the terminal switches to the list of applications method.

Reference: 2RB.015.0 - Book 1 Section 8.3.2 - Selection Using the Payment SystemsDirectory: SELECT PSE returns an error


� LT returns status other than ‘90 00’ or ‘6A 81’ to SELECT PSEcommand

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 terminalselects PSE and sends READ RECORD commands until card respondswith ‘6A 83’ .

Reference: 2RB.017.0 - Book 1 Section 8.3.2 - Indicating end of record


� LT contains several entries and records


Pass Criteria: � LT shall receive a sequence of READ RECORD command until the LTanswers with ‘6A 83’



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 cardanswers with ‘6A 83’ to a READ RECORD for record number 1, theterminal switches to the list of applications method.

Reference: 2RB.018.0 - Book 1 Section 8.3.2 - Directory empty or not present


� LT answers with ‘6A 83’ to a READ RECORD for record number 1


Pass Criteria: � LT shall receive a sequence of SELECT ‘AID’ commands after the LTreturns ‘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 terminalbegins with the first entry of first record of the directory file and processeseach entry in turn

Reference: 2RB.019.0 - Book 1 Section 8.3.2 - Directory entry processing


� LT contains a Directory file with several entries in one record

� Terminal supports all ADF listed in the directory of the LT (for selectionprocess only)







2CB.019.00 Candidate list

Test No. 2CB.019.00

Objective: To ensure that if the terminal supports selection with PSE, the terminaladds the application to the ‘candidate list’ whenever an entry in directory filematches the name of one application supported by the terminal

Reference: 2RB.020.0 - Book 1 Section 8.3.2 - Candidate list


� LT contains a Directory file with several entries.

� Terminal supports all ADF listed in the directory of the LT (for selectionprocess only)





2CB.020.00 Candidate list (implied)

Test No. 2CB.020.00

Objective: To ensure that if the terminal supports selection with PSE, the terminaldoes not add the application to the ‘candidate list’ whenever an entry indirectory file does not match the name of one application supported by theterminal

Reference: 2RB.020.1 - Book 1 Section 8.3.2 - Candidate list (implied)


� LT contains a Directory file with one entry not supported by terminal.

� LT contains only the application listed in Directory file


Pass Criteria: � The terminal shall reject the card (no application mutually supported)



2CB.021.00 DDF entry

Test No. 2CB.021.00

Objective: To ensure that if the terminal supports selection with PSE, the terminal isable 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.


� Terminal supports all ADF listed in the directory of the LT (for selectionprocess only).






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 SELECTDDF command returns a status different from 90 00, the terminal shallresume processing the previously interrupted directory at the point ofinterruption

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 AID’s(before and after DDF entry).

� SELECT DDF returns status different from 90 00







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 yieldno directory entries that match applications supported by the terminal, theterminal switches to the list of applications method.

Reference: 2RB.021.2 - Book 1 Section 8.3.2 - Candidate List empty after selectionwith PSE


� LT supports PSE

� No directory entries matches applications supported by the terminalduring SELECT PSE processing


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 ofAIDs

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.


� LT shall receive SELECT ‘AID’ commands for each applicationsupported by the terminal



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 firstSELECT command using the first AID in the list

Reference: 2RB.022.1 - Book 1 Section 8.3.3 - Selection using a list of AIDs: SELECTcommand

Conditions: � Terminal supports several applications



� LT shall receive the first SELECT ‘AID’ command with the first AID of theterminal 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 answerswith ‘6A 81’ to a SELECT command

Reference: 2RB.023.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs: SELECTfails

Conditions: � The LT answers with ’6A 81” to a SELECT Application command.


Pass Criteria: � The terminal shall terminate the transaction after the SELECTApplication response is returned by the LT



2CB.025.06 DF name and AID identical & SELECT commandsuccessful

Test No. 2CB.025.06

Objective: To ensure that if the DF name and the AID are identical, and SELECTcommand is successful (SW1 SW2 = '9000'), the terminal adds the FCIinformation from the selected file to the candidate list and issues anotherSELECT command using the next AID in its list.

Reference: 2RB.023.6 - Book 1 Section 8.3.3 - DF name and AID identical & SELECTcommand successful

Conditions: � Terminal supports selection by AID

� Terminal supports at least two applications

� LT supports at least the first application presented in the first SELECTcommand (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.


� The terminal shall issue at least three SELECT command including a"final" SELECT command



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 isblocked (SW1 SW2 = '6283'), the terminal issues another SELECTcommand using the next AID in its list without adding the DF name to thecandidate 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.


� The terminal shall issue at least two SELECT command

� The first AID that responded with ’62 83’ shall not be a part of thecandidate list for final select.



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 itsAID list following a status different from ‘90 00’ or ‘6A 81’ or ‘62 83’ returnedby 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 madewith 2 status)

� Terminal supports at least 2 AIDs




� After having sent status different from ‘90 00’ or ‘6A 81’ or ‘62 83’ inanswer to SELECT the specific AID above, the LT shall receive SELECT‘AID’ with AID of next application in the terminal AID list.




2CB.029.00 Selection using a list of AIDs: candidate listcompletion

Test No. 2CB.029.00

Objective: To ensure that the terminal completes the candidate list when there is nomore AID to select in the terminal list.

Reference: 2RB.027.0 - Book 1 Section 8.3.3 - Selection using a list of AIDs: candidatelist completion

Conditions: � The LT contains one AID not supported by the terminal.

� Terminal supports at least 2 AIDs also supported by the LT




� The LT shall receive SELECT AID command for all AID in the terminallist.




2CB.031.00 Application Selection Indicator: One OccurrencePermitted

Test No. 2CB.031.00

Objective: To ensure that if the DFNAME in the ICC is longer than the AID in theterminal, but they are identical up to and including the last character in theterminal AID, the terminal shall check the Application Selection indicator.

If the indicator says only one occurrence is allowed the terminal does notadd the AID to the candidate list and reissues the SELECT command withP2 set to ‘02’

Reference: 2RB.029.00 – Book 1 Section 8.3.3 - Application Selection Indicator: OneOccurrence Permitted

Conditions: � DF Name contained in FCI returned by the LT for first AID selection islonger than terminal AID used for selection but they are identical up toand including the last character in the terminal AID

� Terminal Application Selection Indicator only allows one occurrence forselected AID


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



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 theterminal but are identical up to and including the last character in theterminal AID, the terminal shall check the Application Selection indicator.

If the Application Selection Indicator indicates that multiple occurrence arepermitted and if the application is not blocked, the terminal adds the AID tothe candidate list and repeats the SELECT command using the samecommand 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 & multipleoccurrence & application not blocked

Conditions: � Terminal supports at least one AID

� DF Name contained in FCI returned by the LT for first AID selection islonger than terminal AID used for selection but they are identical up toand including the last character in the terminal AID

� Terminal Application Selection Indicator allows multiple occurrence forselected AID

� LT answers '90 00' to the first SELECT NEXT command


Pass Criteria: � After SELECT AID command, the LT shall receive SELECT ‘AID’ withP2 option set to ‘next ‘

� The terminal shall store the first AID in the candidate list



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 theterminal , but they are identical up to and including the last character in theterminal AID , the terminal shall check the Application Selection indicator.

If the Application Selection Indicator indicates that multiple occurrence arepermitted and if the application is blocked, the terminal does not add theAID to the candidate list and repeats the SELECT command using thesame 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 & multipleoccurrence & application blocked

Conditions: � Terminal supports at least one AID

� DF Name contained in FCI returned by the LT for first AID selection islonger than terminal AID used for selection but they are identical up toand including the last character in the terminal AID

� Terminal Application Selection Indicator allows multiple occurrence forselected AID

� LT answers '62 83' to the first SELECT command


Pass Criteria: � After SELECT AID command, the LT shall receive SELECT ‘AID’ withP2 option set to ‘next ‘ until LT answer is '6A 82'.

� The terminal shall not store the first AID as a selectable application.



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 usingpartial name option if the DF Name returned in FCI is different or shorterthan terminal AID used for selection, but continues processing with nextAID 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 isshorter or different than terminal AID used for selection





� After having sent answer ‘90 00’ and FCI with bad DF Name to firstSELECT AID, the LT shall receive SELECT ‘AID’ with AID of nextapplication in the terminal AID list.




2CB.034.00 Multiple occurrence of application: next optionsupported: 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 tothe candidate list and continues processing Application selection.

Reference: 2RB.031.0 - Book 1 Section 8.3.3 - Multiple occurrence of application: nextoption supported: 90 00


� Terminal’s Application Selection Indicator allows multiple occurrences forthe AID

� LT returns ‘90 00’ to a SELECT command with ‘next’ option (severalapplications with same beginning of AID in LT)



Pass Criteria: � The LT shall receive a sequence of SELECT ‘AID’ with P2 option set to‘next ‘ until LT answer is ‘6A 82’.




2CB.035.00 Multiple occurrence of application: next optionfailed: 62 83

Test No. 2CB.035.00

Objective: To ensure that the terminal does not add the AID in the candidate list whenthe card returns ’62 83’ to a SELECT command with ‘next’ option andproceeds to check for the possibility of multiple occurrences of theapplication 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: nextoption failed: 62 83


� Terminal supports « AID beginning with terminal AID» criteria for theabove 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


Procedure: Perform Application Selection using list of AIDs.

Pass Criteria:

� After having received status ’62 83’ in the response to the selection for aspecific 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 responsecode equal to ’62 83’ indicates that the application is blocked.



2CB.036.00 Multiple occurrence of application: next optionfailed: other

Test No. 2CB.036.00

Objective: To ensure that the terminal proceeds to SELECT the next application in itsAID list, if the card returns status different from ‘90 00’ or ‘62 83’ to aSELECT command with ‘next’ option.

Reference: 2RB.031.2 - Book 1 Section 8.3.3 - Multiple occurrence of application: nextoption failed: other


� LT returns status different from ‘90 00’or ‘62 83’ to a SELECT commandwith ‘next’ option (test is made with several status)



Pass Criteria: � After having sent status different from ‘90 00’or ‘62 83’ in answer toSELECT the specific AID above, the LT shall receive SELECT ‘AID’ withAID of next application in the terminal AID list.

2CB.037.00 Final Selection: no mutually supportedapplication

Test No. 2CB.037.00

Objective: To ensure that the terminal terminate the transaction if there is no mutuallysupported application (candidate list empty).

Reference: 2RB.032.0 - Book 1 Section 8.3.4 - Final Selection: no mutually supportedapplication

Conditions: � There is no matching AID between LT and Terminal


Pass Criteria: � The terminal shall terminate the transaction



2CB.038.00 Final Selection: one mutually supportedapplication

Test No. 2CB.038.00

Objective: To ensure that if only one AID is mutually supported and b8 of Applicationpriority indicator equals 0, the terminal selects this AID.

Reference: 2RB.033.0 - Book 1 Section 8.3.4 - Final Selection: one mutually supportedapplication

Conditions: � There is one matching AID between LT and Terminal

� b8 of Application Indicator returned by LT equals 0


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 Applicationpriority indicator equals 1 and terminal provides for cardholder confirmation,the terminal requests confirmation and selects the application if thecardholder approves.

Reference: 2RB.034.0 - Book 1 Section 8.3.4 - Final Selection: cardholder confirmation



� The terminal provides for cardholder confirmation

� The cardholder approves.


Pass Criteria: � The terminal shall request confirmation of the cardholder and shallgenerate a SELECT AID command as response to that confirmation.



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 Applicationpriority indicator equals 1 and terminal does not provide for cardholderconfirmation, the terminal terminates the transaction.

Reference: 2RB.035.0 - Book 1 Section 8.3.4 - Final Selection: no cardholderconfirmation



� The terminal does not provide for cardholder confirmation

Procedure: Application Selection using list of AID or PSE method.


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 Applicationpriority indicator equals 1 and terminal provides for cardholder confirmationand cardholder does not approve, the terminal terminates the transaction.

Reference: 2RB.036.0 - Book 1 Section 8.3.4 - Final Selection: cardholder does notapprove



� The terminal provides for cardholder confirmation

� Cardholder does not approve

Procedure: Application Selection using list of AID or PSE method.




2CB.042.00 Displaying Application to Cardholder: prioritysequence

Test No. 2CB.042.00

Objective: To ensure that if multiple applications are mutually supported and listdisplay 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.


Pass Criteria: � The terminal shall display a list of applications ordered in prioritysequence (highest priority first)



2CB.049.00 Terminal Selection of Application withoutCardholder Assistance

Test No. 2CB.049.00

Objective: To ensure that if multiple applications are mutually supported and there ispriority sequence and no confirmation is required, the terminal selects theapplication with highest priority.

Reference: 2RB.041.0 - Book 1 Section 8.3.4 - Terminal Selection of Applicationwithout Cardholder Assistance

Conditions: � Terminal does not support the preferred method as described in point 4of final selection EMV process description

� There are several matching AIDs between LT and Terminal


� No confirmation is required in Application priority indicator

� Terminal does not present the list to the cardholder.


Pass Criteria: � The terminal shall select the application with highest priority and shallgenerate the SELECT AID command (with AID=application with highestpriority).



2CB.050.00 Terminal Selection of Application withoutCardholder Assistance: confirmation required

Test No. 2CB.050.00

Objective: To ensure that if multiple applications are mutually supported and listdisplay is not supported, and there is priority sequence and confirmation isrequired for some applications, the terminal selects the application withhighest priority excluding application requiring confirmation

Reference: 2RB.042.0 - Book 1 Section 8.3.4 - Terminal Selection of Applicationwithout Cardholder Assistance: confirmation required

Conditions: � There are several matching AIDs between LT and Terminal


� Application with highest priority requires cardholder confirmation

� Terminal does not present the list to the cardholder.


Pass Criteria: � The terminal shall select the application with highest priority (excludingapplication requiring cardholder confirmation) and shall generate theSELECT AID command (with AID = application with highest priorityexcluding application requiring confirmation).



2CB.053.00 Final Selection of Application from CandidateList: list of AID

Test No. 2CB.053.00

Objective: To ensure that once an application is selected the terminal issue a SELECTcommand using the DF Name read in FCI if selection was performed usinglist of AID.

Reference: 2RB.043.0 - Book 1 Section 8.3.4 - Final Selection of Application fromCandidate List: List of AID



� Terminal uses selection using list of AID process


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 theapplication selected



2CB.054.00 Final Selection of Application from CandidateList: PSE

Test No. 2CB.054.00

Objective: To ensure that if the Terminal supports selection with PSE and performsselection with PSE, it issues a SELECT command using the ADF Nameread in directory.

Reference: 2RB.043.1 - Book 1 Section 8.3.4 - Final Selection of Application fromCandidate List: PSE

Conditions: � LT supports PSE


� There are several matching AID founded between LT and Terminal


� Terminal uses selection using PSE process

Procedure: Application Selection using PSE is performed.


� After having received READ RECORD for all records of the carddirectory, the LT shall receive a SELECT command with ADFName ofthe application with highest priority.

� Terminal shall select the application



2CB.055.00 Final Selection of Application from CandidateList: 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 theSELECT command sent to select the chosen application, the terminalremoves the application from the list of mutually supported applications andswitches back to the final application selection process

Reference: 2RB.044.0 - Book 1 Section 8.3.4 - Final Selection of Application fromCandidate List: SELECT status different from '90 00'



� 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 shallswitch back to the final selection process after the card answered to finalSELECT with status different from '90 00'

� The candidate list generated during the second selection process shallnot contain anymore the application used during the above final SELECT



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 ableto store 6 Certification Authority Public Keys and the key-relatedinformation to be used with the key and it is able, given RID andCertification Authority Public Key Index, to locate such key.

Reference: 2RC.003.00 - Book 2 - Section 5 - Requirements Terminal Must Meet toPerform SDA

Conditions: � Terminal is loaded with 6 Certification Authority Public Keys andassociated 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 (inparticular Static Data Authentication).


� TVR byte 1, bit 7 = ‘0’ ie Offline Static Data Authentication succeeded

� TSI byte 1, bit 8 = ‘1’ ie Offline Data Authentication was performed



2CC.004.00 Algorithm For SDA

Test No. 2CC.004.00

Objective: To ensure that the terminal supports reversible algorithm for Static DataAuthentication 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 reversiblealgorithm)









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 amultiple 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









2CC.007.00 Value of Certification Authority Public KeyExponent

Test No. 2CC.007.00

Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent forCertification Authority Public Key for Static Data Authentication

Reference: 2RC.007.0, Book 2 - Section 5.1 - Value of Certification Authority PublicKey Exponent


� Exponent of Certification Authority Public Key is 3 or 216 + 1 (2 valuestested)









2CC.008.00 Value of Issuer Public Key Exponent

Test No. 2CC.008.00

Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent forIssuer Public Key for Static Data Authentication

Reference: 2RC.008.0, Book 2 - Section5.1 - Value of Issuer Public Key Exponent


� Exponent of Issuer Public Key is 3 or 216 + 1 (2 values tested)









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 inICC, 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





� TVR byte 1, bit 7 = ‘1’ ie Offline Static Data Authentication failed

� TVR byte 1, bit 6 = ‘1’ ie ICC data missing




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, theterminal 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










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, theterminal 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










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, theterminal fails the Static Data Authentication

Reference: 2RC.009.3, Book 2 - Section 5.1 - Data missing: Signed Static Applicationdata

Conditions: � Signed Static Application Data is missing in ICC










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 noCertification Authority Public Keys is available for a given RID andCertification Authority Public Key Index, the terminal fails the Static DataAuthentication.

Reference: 2RC.011.0 , Book 2 - Section 5.2 - Retrieving CA Public Key used toPerform SDA: Key absent

Conditions: � Terminal does not contain the Certification Authority Public Keyreferenced in LT









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 ifIssuer Public Key Certificate has a length different from CertificationAuthority Public Key Modulus, the terminal fails the Static DataAuthentication.

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 fromCertification Authority Public Key Modulus in Terminal









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 DataTrailer 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 Trailerdifferent from ‘BC’









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 DataHeader 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 Headerdifferent from ‘6A’









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 theCertificate Format recovered from Issuer Public Key Certificate does notequal ‘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 Formatdifferent from ‘02’









2CC.020.00 Difference between calculated Hash Result andrecovered Hash Result

Test No. 2CC.020.00

Objective: To ensure that the terminal fails the Static Data Authentication, if thecalculated Hash Result is different from the Hash Result recovered from theIssuer Public Key Certificate

Reference: 2RC.017.0 , Book 2 - Section 5.3 - Difference between calculated HashResult and recovered Hash Result

Conditions: � Issuer Public Key Certificate in LT is calculated with a bad Hash value









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 theRecovered Issuer Identification Number does not match the leftmost 3-8PAN digits

Reference: 2RC.018.0 , Book 2 - Section 5.3 - IIN does not match leftmost 3-8 PANdigits

Conditions: � Issuer Public Key Certificate in LT is calculated with IIN different fromleftmost 3-8 PAN digits









2CC.022.00 Certificate Expiration Date earlier than today’sdate

Test No. 2CC.022.00

Objective: To ensure that the terminal fails the Static Data Authentication, if theCertificate Expiration Date has expired

Reference: 2RC.019.0 , Book 2 - Section 5.3 - Certificate Expiration Date earlier thantoday’s date

Conditions: � Issuer Public Key Certificate in LT is calculated with CertificateExpiration Date earlier than the current date









2CC.023.00 RID, CA Public Key Index and Certificate SerialNumber not valid

Test No. 2CC.023.00

Objective: To ensure that the terminal fails the Static Data Authentication, if theconcatenation of RID, CA Public Key Index and Certificate Serial Numberindicates a revocated Certificate

Reference: 2RC.020.0 , Book 2 - Section 5.3 - RID, CA Public Key Index andCertificate Serial number not valid

Conditions: � Issuer Public Key Certificate in LT is calculated with RID, CA Public KeyIndex and Certificate Serial Number such as the certificate is in therevocation list of the terminal

� Terminal supports revocation of the Issuer Public Key Certificate









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 IssuerPublic Key Algorithm is not supported (different from ‘01’)

Reference: 2RC.021.0 , Book 2 - Section 5.3 - Issuer Public Key Algorithm notrecognised

Conditions: � Issuer Public Key Certificate in LT is calculated with Issuer Public KeyAlgorithm value different from ‘01’









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 ifSigned Static Application Data has a length different from Issuer Public KeyModulus, the terminal fails the Static Data Authentication.

Reference: 2RC.023.0 , Book 2 - Section 5.4 - Signed Static Application Data Lengthnot OK

Conditions: � Signed Static Application Data has a length different from Issuer PublicKey Modulus in ICC









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 DataTrailer 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 Trailerdifferent from ‘BC’









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 DataHeader 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 Headerdifferent from ‘6A’










Test No. 2CC.030.00

Objective: To ensure that the terminal fails the Static Data Authentication, if theCertificate Format recovered from Signed Static Application Data does notequal ‘03’


Conditions: � Signed Static Application Data in LT is calculated with a CertificateFormat different from ‘03’










Test No. 2CC.031.00

Objective: To ensure that the terminal fails the Static Data Authentication, if thecalculated Hash Result is different from the Hash Result recovered fromSigned Static Application Data


Conditions: � Signed Static Application Data in LT is calculated with a bad Hash value









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 inSDA

Reference: 2RC.032.0 - Book 1 - Section 5.1 & Book 2 Section 5.4 - Static Data to beAuthenticated

Conditions: � ICC and Terminal support SDA

� CDOL1 requests also TSI and TVR

� SDA Tag List contains AFL



� TVR byte 1, bit 7 = ‘1’ ie Offline SDA failed




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 '9F45'

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'



� TVR byte 1, bit 7 = ‘0’ ie Offline SDA succeeded


� Value of Tag '9F 45' is 'DA C0' in CDOL1



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 isable to store 6 Certification Authority Public Keys and the key-relatedinformation to be used with the key and it is able, given RID andCertification Authority Public Key Index, to locate such key.

Reference: 2RC.029.00, Book 2 - Section 6 - Requirements Terminal Must Meet toSupport DDA

Conditions: � Terminal is loaded with 6 Certification Authority Public Keys andassociated 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




� TVR byte 1, bit 4= ‘0’ ie Offline Dynamic Data Authentication succeeded




2CC.037.00 Algorithm for DDA

Test No. 2CC.037.00

Objective: To ensure that the terminal supports reversible algorithm for Dynamic DataAuthentication 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 thereversible algorithm)





� TVR byte 1, bit 4 = ‘0’ ie Offline Dynamic Data Authentication succeeded




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 amultiple 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









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 forCertification Authority Public Key for Dynamic Data Authentication

Reference: 2RC.037.0 , Book 2 - Section 6.1 - Value of CA Public Key Exponent


� Exponent of Certification Authority Public Key is 3 or 216 + 1 (2 valuestested)









2CC.041.00 Value of Issuer Public Key Exponent

Test No. 2CC.041.00

Objective: To ensure that the terminal supports value 3 or 216 + 1 as exponent forIssuer Public Key for Dynamic Data Authentication

Reference: 2RC.038.0 , Book 2 - Section 6.1 - Value of Issuer Public Key Exponent


� Exponent of Issuer Authority Public Key is 3 or 216 + 1 (2 values tested)









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 ICCPublic Key for Dynamic Data Authentication

Reference: 2RC.039.0 , Book 2 - Section 6.1 - Value of ICC Public Key Exponent


� Exponent of ICC Authority Public Key is 3 or 216 + 1 (2 values tested)









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 inICC, 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




� TVR byte 1, bit 4 = ‘1’ ie Offline Dynamic Data Authentication failed





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, theterminal fails the Dynamic Data Authentication

Reference: 2RC.040.1 , Book 2 - Section 6.1 - Data missing: Issuer Public KeyCertificate


� Issuer Public Key Certificate is missing in ICC









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, theterminal fails the Dynamic Data Authentication

Reference: 2RC.040.2 , Book 2 - Section 6.1 - Data missing: Issuer PK Exponent


� Issuer Public key Exponent is missing in ICC









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, theterminal fails the Dynamic Data Authentication

Reference: 2RC.040.3 , Book 2 - Section 6.1 - Data missing: ICC Public Key Certificate


� ICC Public Key Certificate is missing in ICC









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, theterminal fails the Dynamic Data Authentication

Reference: 2RC.040.4 , Book 2 - Section 6.1 - Data missing: ICC Public Key Exponent


� ICC Public key Exponent is missing in ICC









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 noCertification Authority Public Keys is available for a given RID andCertification Authority Public Key Index, the terminal fails the Dynamic DataAuthentication

Reference: 2RC.042.0 , Book 2 - Section 6.2 - Retrieving CA Public Key used toPerform DDA


� Terminal does not contain the Certification Authority Public Keyreferenced in LT








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 ifIssuer Public Key Certificate has a length different from CertificationAuthority Public Key Modulus, the terminal fails the Dynamic DataAuthentication.

Reference: 2RC.043.0 , Book 2 - Section 6.3 - Length of Issuer Public Key Certificate


� Issuer Public Key Certificate in LT has a length different fromCertification Authority Public Key Modulus in Terminal









Test No. 2CC.052.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Trailer recovered from the Issuer Public Key Certificate does notequal ‘BC’.



� Issuer Public Key Certificate in LT is calculated with a Data Trailerdifferent from ‘BC’









Test No. 2CC.053.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Header recovered from the Issuer Public Key Certificate does notequal ‘6A’.



� Issuer Public Key Certificate in LT is calculated with a Data Headerdifferent from ‘6A’









Test No. 2CC.054.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theCertificate Format recovered from Issuer Public Key Certificate does notequal ‘02’.



� Issuer Public Key Certificate in LT is calculated with a Certificate Formatdifferent from ‘02’









Test No. 2CC.055.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if thecalculated Hash Result is different from the Hash Result recovered from theIssuer Public Key Certificate.



� Issuer Public Key Certificate in LT is calculated with a bad Hash value








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 theRecovered Issuer Identification Number does not match the leftmost 3-8PAN digits.

Reference: 2RC.049.0 , Book 2 - Section 6.3 - IIN does not match leftmost 3-8 PANdigits


� Issuer Public Key Certificate in LT is calculated with IIN different fromleftmost 3-8 PAN digits









Test No. 2CC.057.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theCertificate Expiration Date has expired.



� Issuer Public Key Certificate in LT is calculated with CertificateExpiration Date earlier than the current date








2CC.058.00 RID, CA Public Key Index and Certificate SerialNumber not valid

Test No. 2CC.058.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theconcatenation of RID, CA Public Key Index and Certificate Serial Numberindicates a revocated Certificate.

Reference: 2RC.051.0 , Book 2 - Section 6.3 - RID, CA Public Key Index andCertificate Serial number not valid

Conditions: � Terminal supports revocation of the Issuer Public Key Certificate


� Issuer Public Key Certificate in LT is calculated with RID, CA Public KeyIndex and Certificate Serial Number such as the certificate is in therevocation list of the terminal








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 theIssuer Public Key Algorithm is not supported (different from ‘01’).

Reference: 2RC.052.0 , Book 2 - Section 6.3 - Issuer Public Key Algorithm notrecognised


� Issuer Public Key Certificate in LT is calculated with Issuer Public KeyAlgorithm value different from ‘01’








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 ifICC Public Key Certificate has a length different from Issuer Public KeyModulus, the terminal fails the Dynamic Data Authentication.

Reference: 2RC.054.0 , Book 2 - Section 6.4 - Length of ICC Public Key Certificate


� ICC Public Key Certificate in LT has a length different from recoveredIssuer Public Key Modulus









Test No. 2CC.063.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Trailer recovered from the ICC Public Key Certificate does not equal‘BC’.



� ICC Public Key Certificate in LT is calculated with a Data Trailer differentfrom ‘BC’









Test No. 2CC.064.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Header recovered from the ICC Public Key Certificate does not equal‘6A’.



� ICC Public Key Certificate in LT is calculated with a Data Headerdifferent from ‘6A’









Test No. 2CC.065.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theCertificate Format recovered from ICC Public Key Certificate does notequal ‘04’.



� ICC Public Key Certificate in LT is calculated with a Certificate Formatdifferent from ‘04’









Test No. 2CC.066.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if thecalculated Hash Result is different from the Hash Result recovered from theICC Public Key Certificate.



� ICC Public Key Certificate in LT is calculated with a bad Hash value








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 theRecovered 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 readPAN


� Issuer Public Key Certificate in LT is calculated with PAN different fromPAN in LT









Test No. 2CC.068.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theCertificate Expiration Date has expired.



� ICC Public Key Certificate in LT is calculated with Certificate ExpirationDate earlier than the current date








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 theICC Public Key Algorithm is not supported (different from ‘01’).

Reference: 2RC.062.0 , Book 2 - Section 6.4 - ICC Public Key Algorithm notrecognised


� ICC Public Key Certificate in LT is calculated with Issuer Public KeyAlgorithm value different from ‘01’








2CC.071.00 Dynamic Signature generation

Test No. 2CC.071.00

Objective: To ensure that if Dynamic Data Authentication is supported, the terminal isable to issue an INTERNAL AUTHENTICATE command including dataelements specified in DDOL.

Reference: 2RC.064.0 , Book 2 - Section 6.5.1 - Dynamic Signature generation


� DDOL is present in LT

� Dynamic signature computed by LT is good





� The LT shall receive an INTERNAL AUTHENTICATE command withconcatenation of data in DDOL according to rule described in Book 3Section 1.4




2CC.072.00 Default DDOL

Test No. 2CC.072.00

Objective: To ensure that if Dynamic Data Authentication is supported, and card doesnot contain DDOL, the terminal is able to use its default DDOL.

Reference: 2RC.065.0 , Book 2 - Section 6.5.1 - Default DDOL


� DDOL is absent in LT

� Default DDOL is present in terminal






� The LT shall receive an INTERNAL AUTHENTICATE command withconcatenation of data in default DDOL according to rule described inBook 3 Section1.4




2CC.074.00 Source of Unpredictable Number

Test No. 2CC.074.00

Objective: To ensure that if Dynamic Data Authentication is supported and the DDOLrequests an unpredictable Number, the terminal send an INTERNALAUTHENTICATE command containing this number on 4 bytes

Reference: 2RC.066.0 , Book 2 - Section 6.5.1 - Source of Unpredictable Number


� DDOL requests 9F 37 on 4 bytes






� The LT shall receive an INTERNAL AUTHENTICATE command withunpredictable Number contained in the data field




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 DDOLin card does not request an unpredictable Number, the terminal fails theDynamic Data Authentication

Reference: 2RC.067.0 , Book 2 - Section 6.5.1 - DDOL does not contain unpredictablenumber


� DDOL in LT does not request 9F 37

� default DDOL in terminal requests 9F 37








2CC.076.00 Default DDOL does not contain unpredictableNumber

Test No. 2CC.076.00

Objective: To ensure that if Dynamic Data Authentication is supported, and the carddoes not contain DDOL and the default DDOL in terminal does not requestan unpredictable Number, the terminal fails the Dynamic DataAuthentication

Reference: 2RC.068.0 , Book 2 - Section 6.5.1 - Default DDOL does not containunpredictable number


� DDOL is absent in LT

� default DDOL in terminal does not request 9F 37








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 ifSigned Dynamic Application Data has a length different from ICC PublicKey Modulus, the terminal fails the Dynamic Data Authentication.

Reference: 2RC.070.0 , Book 2 - Section 6.5.2 - Signed Dynamic Application DataLength not OK


� Signed Dynamic Application Data computed by LT has a length differentfrom ICC Public Key Modulus








2CC.079.00 Recovery Function

Test No. 2CC.079.00

Objective: To ensure that the terminal is able to perform the recovery function on theSigned Dynamic Application Data for Dynamic Data Authentication asspecified in Book 2, A2.1

Reference: 2RC.071.0 , Book 2 Annex A2.1- Recovery Function


� Signed Dynamic Application Data computed by LT is good

� Issuer Public Key Certificate is good

� ICC public Certificate is good









Test No. 2CC.080.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Trailer recovered from the Signed Dynamic Application Data does notequal ‘BC’.

Reference: 2RC.072.0 , Book 2 - Section 6.5.2 - Recover Data Trailer not equal to ‘BC’


� Signed Dynamic Application Data is calculated by LT with a Data Trailerdifferent from ‘BC’









Test No. 2CC.081.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theData Header recovered from the Signed Dynamic Application Data does notequal ‘6A’.

Reference: 2RC.073.0 , Book 2 - Section 6.5.2 - Recover Data Header not equal to ‘6A’


� Signed Dynamic Application Data is calculated by LT with a Data Headerdifferent from ‘6A’









Test No. 2CC.082.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if theCertificate Format recovered from Signed Dynamic Application Data doesnot equal ‘05’.

Reference: 2RC.074.0 , Book 2 - Section 6.5.2 - Certificate Format not equal to ‘05’


� Signed Dynamic Application Data is calculated by LT with a CertificateFormat different from ‘05’









Test No. 2CC.083.00

Objective: To ensure that the terminal fails the Dynamic Data Authentication, if thecalculated Hash Result is different from the Hash Result recovered from theSigned Dynamic Application Data.

Reference: 2RC.075.0 , Book 2 - Section 6.5.2 - Difference between calculated HashResult and recovered Hash Result


� Signed Dynamic Application Data is calculated by LT with a bad Hashvalue








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, theterminal succeeds the Dynamic Data Authentication.

Reference: 2RC.076.0 , Book 2 - Section6.5.2 - Dynamic Data Authentication is OK










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 inDDA

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



� TVR byte 1, bit 4 = ‘1’ ie Offline DDA failed




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'



� TVR byte 1, bit 4 = ‘0’ ie Offline DDA succeeded


� Value of Tag '9F 4C' shall be the same as used in DDA



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 touse a PIN encipherment public key stored in the card to encrypt the PINand 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'




� Once deciphered with PIN encipherment private Key, the LT shallrecover a the PIN value presented within the PIN block and theunpredictable Number generated by LT


� TVR byte 3, bit 8=’0’ ie Cardholder verification was successful



2CC.094.00 Random behaviour of PIN Encipherment paddingpattern

Test No. 2CC.094.00

Objective: To ensure that if the terminal supports offline PIN encryption, it is able togenerate a RANDOM pattern of N-17 bytes.

Reference: 2RC.096.0, Book 2 - Section 7.2 - Random Padding Pattern





Procedure: Several transactions are processed with LT (in particular Cardholderverification).


� Once deciphered with PIN encipherment private Key, the LT shallrecover the PIN value presented within the PIN block and theunpredictable Number generated by LT

� The tester shall check the "random behaviour" of the padding patterncomparing values from different transactions.





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 ICCPIN Encipherment Public Key for PIN encryption

Reference: 2RC.087.0 , Book 2 - Section 7.1 - Value of ICC PIN Encryption Public KeyExponent




� Exponent of ICC PIN Encipherment Public Key is 3 or 216 + 1 (2 valuestested)



� Once deciphered with PIN encipherment private Key, the LT shallrecover the PIN value presented and unpredictable Number generatedby LT



2CC.096.00 ICC PIN Encipherment Public Key recovering: ICCPIN Encipherment Public Key

Test No. 2CC.096.00

Objective: To ensure that if the terminal supports offline PIN encryption, it is able toretrieve the ICC PIN encipherment Public Key if data in table 20, Book 2 ispresent in the card.

Reference: 2RC.089.0 , Book 2 - Section 7.1 - ICC PIN Encipherment Public Keyrecovering: ICC PIN Encipherment Public Key


� 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.




� Once deciphered with PIN encipherment private Key, the LT shallrecover the PIN value presented and unpredictable Number generatedby LT



2CC.097.00 ICC PIN Encipherment Public Key recovery: ICCIssuer Public Key

Test No. 2CC.097.00

Objective: To ensure that if the terminal supports offline PIN encryption, it is able toretrieve the ICC Public Key if data in table 20, Book 2, is not present in thecard, but all data elements in table 8, Book 2, are present in the ICC, if ICCPublic Key Exponent is = 3 or 216 +1.

Reference: 2RC.090.0 , Book 2 - Section 7.1 - ICC PIN Encipherment Public Keyrecovering ICC Issuer Public Key


� 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 elementsin table 11, Book 2 are present in the LT, if the ICC Public Key Exponentis = 3 or 216 +1.





� Once deciphered with ICC private Key, the LT shall recover the PINvalue presented within the PIN block and the unpredictable Numbergenerated by LT





2CC.098.00 ICC PIN Encipherment Public Key recoveringfailed

Test No. 2CC.098.00

Objective: To ensure that if the terminal supports offline PIN encryption, and if it is notable 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 Keyrecovering failed


� PIN Encipherment Public Key Certificate is not good in LT





� TVR byte 3, bit 8 = ‘1’ ie Cardholder verification was not successful



2CC.099.00 PIN Entry

Test No. 2CC.099.00

Objective: To ensure that if the terminal supports offline PIN encryption, it asks thecardholder to enter his PIN on the PIN Pad, and encrypts it beforepresentation to the card

Reference: 2RC.092.0 , Book 2 - Section 7.2 - PIN Entry






� The terminal (PIN Pad) shall asks for PIN entry

� Once deciphered with PIN encipherment private Key, the LT shallrecover the PIN Block on 8 bytes and the PIN entered in plaintext format



2CC.100.00 Unpredictable Number

Test No. 2CC.100.00

Objective: To ensure that if the terminal supports offline PIN encryption, it issues aGET CHALLENGE command to obtain an unpredictable Number from thecard

Reference: 2RC.093.0 , Book 2 - Section 7.2 - Unpredictable Number






� 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 toencrypt the PIN data using the recovery function specified in Book 2

Reference: 2RC.094.0 , Book 2 - Section 7.2 - Enciphered PIN Data






� Once deciphered with PIN encipherment private Key, the LT shallrecover a PIN Block on 8 bytes and the PIN entered in plaintext format



2CC.102.00 VERIFY

Test No. 2CC.102.00

Objective: To ensure that if the terminal supports offline PIN encryption, it issues aVERIFY command containing the Enciphered PIN Data

Reference: 2RC.095.0 , Book 2 - Section 7.2 - VERIFY






� The LT shall receive a VERIFY command from the terminal withEnciphered PIN Data in the data field



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 bythe 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 (inparticular Enhanced Combined DDA/AC).


� 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



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 UnpredictableNumber (tag 9F 37) in CDOL1


Conditions: � CDOL1 in LT does not include Unpredictable Number generated by theterminal (tag 9F 37)


� CDOL2 includes TVR, TSI and Unpredictable Number



� TVR byte 1, bit 3 = ‘1’ i.e. Combined DDA/AC Generation failed




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 UnpredictableNumber (tag 9F 37) in CDOL2


Conditions: � CDOL1 in LT includes Unpredictable Number generated by the terminal(tag 9F 37)


� CDOL2 does not include Unpredictable Number

� First GENERATE AC response from LT is ARQC



� TVR and TSI (contained in Financial Confirmation message or BatchData Captured message or other) shall have:





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 LTresponds AAC




� LT responds AAC at the first generate AC



� The transaction shall be declined.

The following pass criteria only applies if the terminal has the ability to storedeclined transactions:

� TVR byte 1, bit 3 shall be set to ‘1’ indicating Combined DDA/ACGeneration failed.



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 LTresponds AAC




� LT responds ARQC at the first generate AC

� LT responds AAC at the second generate AC



� The transaction shall be declined.

The following pass criteria only applies if the terminal has the ability to storedeclined transactions.




2CC.123.00 Signed Dynamic Application Data Length

Test No. 2CC.123.00

Objective: To ensure that the terminal compare the Signed Dynamic Application Datalength with the ICC Public Key length




� Length of Signed Dynamic Application Data is different from the ICCPublic Key length








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




� Data trailer is different from BC








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




� Data header is different from 6A








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




� Signed Data Format is different from 05








2CC.127.00 Recovered CID different from CID obtained afterGenerate AC (1)

Test No. 2CC.127.00

Objective: To ensure that the terminal checks that the CID recovered is the same asthe one transmitted in the response to the Generate AC




� LT responds with TC

� CID in signature is ARQC








2CC.127.01 Recovered CID different from CID obtained afterGenerate AC (2)

Test No. 2CC.127.01

Objective: To ensure that the terminal checks that the CID recovered is the same asthe one transmitted in the response to the Generate AC.


Conditions: � CDOL1 and CDOL2 in LT includes Unpredictable Number generated bythe terminal (tag 9F 37)


� LT responds with a ARQC

� CID in signature is TC








2CC.128.00 Compare hash result

Test No. 2CC.128.00

Objective: To ensure that the terminal compares the hash result




� Hash result is corrupted








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




� Transaction Data Hash result is corrupted








2CC.130.00 Issuer Application Data in Enhanced CombinedDDA/AC

Test No. 2CC.130.00

Objective: To ensure that the terminal can use Issuer Application Data in EnhancedCombined DDA/AC




� Issuer Application Data is present as response of Generate AC.








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






� TVR, TSI and ICC Dynamic Number (contained in FinancialConfirmation message or Batch Data Captured message or other) shallhave:



� ICC Dynamic Number stored in Tag 9F 4C is the same as the oneused in Enhanced Combined DDA/AC



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






� TVR, TSI and Application Cryptogram (contained in FinancialConfirmation message or Batch Data Captured message or other)shall have:



� Application Cryptogram stored in Tag 9F 26 is the same as the oneused in Enhanced Combined DDA/AC



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 oneto another transaction





Procedure: Several transactions are processed. The unpredictable number valuesgenerated by the terminal will be compared.




� Tag 9F37 is checked and compared with the one from the previoustransaction. They shall be different.



2CC.135.00 Signed Dynamic Application Data is not present inresponse 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.




� LT answers an TC

� Tag 9F4B is not present in response to the Generate AC


Pass Criteria: � The terminal shall process the transactions to completion.

� The transaction shall be declined





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 specifiedby CDOL1 for Enhanced Combined DDA/AC at the 2nd Generate AC.




� CDOL1 and CDOL2 requests TSI and TVR.

� LT sends an ARQC at 1st Generate AC, Enhanced Combined DDA/AC iscorrect at the 1st Generate AC.

� LT sends a TC at 2nd Generate AC, Enhanced Combined DDA/AC iscorrect at the 2nd Generate AC.








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 specifiedby PDOL for Enhanced Combined DDA/AC at the 2nd Generate AC.




� LT sends an ARQC at 1st Generate AC, Enhanced Combined DDA/AC iscorrect at the 1st Generate AC.

� LT sends a TC at 2nd Generate AC, Enhanced Combined DDA/AC iscorrect at the 2nd Generate AC.

� PDOL is present in LT (Value indicated by PDOL will change betweenthe 1st and the 2nd Generate AC).








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 1byte (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 forinstance)


Pass Criteria: � The terminal shall process the transaction until completion and shallmanage 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 2bytes (81 xx)


Conditions: � LT contains Data Object to be read with length on 2 bytes


Pass Criteria: � The terminal shall process the transaction until completion and shallmanage correctly the Data Object with length on 2 bytes received.



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 3bytes (82 xx xx)


Conditions: � LT contains Data Object to be read with length on 3 bytes


Pass Criteria: � The terminal shall process the transaction until completion and shallmanage correctly the Data Object with length on 3 bytes received.



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 AnnexA 2.1

Reference: 2RG.002.0 - Book 2 Annex A - Signature verification

Conditions: � Issuer Public Key Certificate and Static signature in LT are good








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 withlength verifying NIC � NI � NCA (respectively NI � NCA ).

Reference: 2RH.001.0 - Book 2 Annex B2 Section 1 - The Relationship Between theLengths 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 , Dynamicsignature computed by LT is good

2. LT supports Static Data Authentication , NI � NCA , Static signature inLT is good


Procedure: Application in LT is selected and transaction is processed with LT (inparticular Dynamic or Static Data Authentication).


� TVR byte 1, bit 4 = ‘0’ or bit 7 =‘0’ ie Offline Dynamic or Static DataAuthentication succeeded




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 valueequal to ‘01’

Reference: 2RH.003.0 - Book 2 Annex B2 Section 1 - Coding the Public Key AlgorithmIndicator

Conditions: � Issuer Public Key Certificate in LT is calculated with Issuer Public KeyAlgorithm value equal to ‘01’








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 withmaximum 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 signaturecomputed by LT is good

2. LT supports Static Data Authentication , length NI = 248 bytes, lengthNCA = 248 bytes, Static signature in LT is good


Procedure: Application in LT is selected and transaction is processed with LT (inparticular Dynamic or Static Data Authentication).


� TVR byte 1, bit 4 = ‘0’ or bit 7 =‘0’ ie Offline Dynamic or Static DataAuthentication succeeded

TSI byte 1, bit 8 = ‘1’ ie Offline Data Authentication was performed



2CH.010.00 Coding of Hash Algorithm Indicator

Test No. 2CH.010.00

Objective: To ensure that the terminal supports Hash Algorithm Indicator value equalto ‘01’

Reference: 2RH.011.0 - Book 2 Annex B3 Section 1 - Coding of Hash AlgorithmIndicator

Conditions: � Issuer Public Key Certificate in LT is calculated with Hash AlgorithmIndicator value equal to ‘01’








ICC Application Specification for PaymentSystem, Test Case Description

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 to10 (0x01 to 0x0A) using READ RECORD command

Reference: 2RI.001.0 - Book 3 Section 3 - READ RECORD with the Short FileIdentifiers (SFI) ranged from 1 to 10

Conditions: � One Mandatory Data Element (PAN for instance) is located in file withSFI in range 01 to 10 (test is made with all values in range)





2CI.002.00 READ RECORD in linear files

Test No. 2CI.002.00

Objective: To ensure that the terminal is able to read data in file with linear structureand 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 withlinear structure and records with fix size

� Another Mandatory Data Element (Expiration Date for Instance) islocated in file with linear structure and records with variable size



2CI.003.00 READ RECORD in files containing multiplerecords

Test No. 2CI.003.00

Objective: To ensure that the terminal is able to read data in file with several recordsusing READ RECORD command

Reference: 2RI.003.0 - Book 3 Section 3 - READ RECORD in files containing multiplerecords

Conditions: � One Mandatory Data Element (PAN for instance) is located in firstrecord of a file

� Another Mandatory Data Element (Expiration Date for Instance) islocated in second record of same file

� Another Mandatory Data Element (CDOL1 and CDOL2 for Instance) islocated in third record of same file





2CI.004.00 READ RECORD with the record size in the rangefrom 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 inrange from 1 to 254 bytes using READ RECORD command

Reference: 2RI.004.0 - Book 3 Section 3 - READ RECORD with the record size in therange from 1 to 254 bytes

Conditions: � A record containing only the template and length equals to 00 (70 00) islocated in a single record

� A Data Element with ‘average length’ is located in a single record (forinstance Signed Static Application Data or CDOL1)

� A Data Element with maximum length (Total length including Tag andLength and Template is 254) is located in a single record (for instanceCDOL1)



2CI.005.00 Record Data Format

Test No. 2CI.005.00

Objective: To ensure that the terminal is able to extract data read in record fromtemplate 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





2CI.007.00 Free access conditions for files accessible usingthe READ RECORD command

Test No. 2CI.007.00

Objective: To ensure that the terminal is able to read data in a file with free accessconditions

Reference: 2RI.007.0 - Book 3 Section 3 - Free access conditions for files accessibleusing the READ RECORD command

Conditions: � Mandatory Data Elements are located in a file with free accessconditions



2CI.008.00 READ RECORD in the Application File Locator

Test No. 2CI.008.00

Objective: To ensure that the terminal is able to interpret the AFL and read data in thecard using READ RECORD command according to the AFL information

Reference: 2RI.008.0 - Book 3 Section 3 - READ RECORD in the Application FileLocator

Conditions: � AFL bytes 1,2, & 3 are tested in the LT


Pass Criteria: � The LT shall receive a sequence of READ RECORD commandsaccording to the AFL



2CI.009.00 Mandatory Data Objects: Application ExpirationDate

Test No. 2CI.009.00

Objective: To ensure that the terminal checks that mandatory Data Object ApplicationExpiration Date is present in the card and is able to use it.

Reference: 2RI.010.0 - Book 3 Section 3.1 - Mandatory Data Objects: ApplicationExpiration Date

Conditions: � Application Expiration Date is present in LT



2CI.010.00 Mandatory Data Objects: PAN

Test No. 2CI.010.00

Objective: To ensure that the terminal checks that mandatory Data Object PAN ispresent 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





2CI.011.00 Mandatory Data Objects: CDOL 1

Test No. 2CI.011.00

Objective: To ensure that the terminal checks that mandatory Data Object CDOL1 ispresent 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


Pass Criteria: � The terminal shall send the first Generate AC with the data requested inCDOL1

2CI.012.00 Mandatory Data Objects: CDOL 2

Test No. 2CI.012.00

Objective: To ensure that the terminal checks that mandatory Data Object CDOL2 ispresent 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


Pass Criteria: � The terminal shall send an 2nd Generate AC with the data requested inCDOL2



2CI.013.00 Optional Data Objects:

Test No. 2CI.013.00

Objective: To ensure that the terminal accepts presence or absence of optional DataObject.

Reference: 2RI.010.4 - Book 3 Section 3.1 - Optional Data Objects

Conditions: � Test is made with presence and absence of Optional Data Objects: (AllData Objects coming from card and read with READ RECORD exceptthose listed in Book 3 table II-2, table II-3, table II-4.





2CI.014.00 Mandatory Data Objects for Offline Static DataAuthentication

Test No. 2CI.014.00

Objective: To ensure that the terminal checks that if supported, mandatory DataObjects for Offline Static Data Authentication are present in the card and itis able to use them.

Reference: 2RI.011.0 - Book 3 Section 3.1 - Mandatory Data Objects for Offline StaticData 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 Keyused in this test case shall allow the issuer public Key remainder to bepresent)

� Issuer Public Key Exponent is present in LT




� 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



2CI.015.00 Mandatory Data Objects for Offline Dynamic DataAuthentication

Test No. 2CI.015.00

Objective: To ensure that the terminal checks that if supported, mandatory DataObjects for Offline Dynamic Data Authentication are present in the card andit is able to use them.

Reference: 2RI.012.0 - Book 3 Section 3.1 - Mandatory Data Objects for OfflineDynamic 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 Keyused in this test case shall allow the issuer public Key remainder to bepresent)

� 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 usedin 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





� TVR byte 1, bit 6 = ‘0’ ie No ICC Data missing

� TSI byte 1 bit 8= ’1’ ie. Offline Data authentication was performed



2CI.017.00 GET DATA on PIN Try Counter

Test No. 2CI.017.00

Objective: To ensure that the terminal is able to retrieve the PTC using the GET DATAcommand

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



� LT shall receive a GET DATA command ( 80 CA 9F 17 )

2CI.018.00 GET DATA on Last Online ATC Register

Test No. 2CI.018.00

Objective: To ensure that the terminal is able to retrieve the LOATC using the GETDATA 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


� LT supports Terminal Risk Management







2CI.019.00 Both the LCOL and UCOL data objects exist in theICC

Test No. 2CI.019.00

Objective: To ensure that the terminal retrieves the ATC using the GET DATAcommand when Lower and Upper consecutive Offline limits are present inthe card

Reference: 2RI.016.0 - Book 3 Section 3.2 - Both the Lower and the UpperConsecutive Offline Limit data objects exist in the ICC

Conditions: � Lower and Upper consecutive Offline limits are present in LT

� Terminal supports Velocity Checking


� LT supports terminal risk management







2CI.020.00 Either the LCOL or the UCOL data objects is notpresent in the ICC

Test No. 2CI.020.00

Objective: To ensure that the terminal abort velocity checking when either Lower orUpper consecutive Offline limits are not present in the card

Reference: 2RI.017.0 - Book 3 Section 3.2 - Either the Lower or the Upper ConsecutiveOffline 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


Pass Criteria: � Terminal will terminate Velocity checking, The terminal shall process thetransaction 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 9F13)



2CI.021.00 Data retrievable by GET PROCESSING OPTIONScommand

Test No. 2CI.021.00

Objective: To ensure that the terminal is able to retrieve and understand both AFL andAIP, using the GET PROCESSING OPTIONS

Reference: 2RI.018.0 - Book 3 Section 3.3 - Data retrievable by GET PROCESSINGOPTIONS 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 onlinecapability



� 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 optionssupported in AIP (Offline Authentication, Cardholder Verification,Terminal Risk Management and Issuer Authentication)



2CI.022.00 Functions specified in the AIP: Offline Static DataAuthentication

Test No. 2CI.022.00

Objective: To ensure that the terminal performs Offline Static Data Authentication ifsupported in AIP

Reference: 2RI.019.0 - Book 3 Section 4 - Functions specified in the ApplicationInterchange Profile: Offline Static Data Authentication

Conditions: � AIP returned by LT specifies that Offline Static Data Authentication issupported and not Offline Dynamic Data Authentication

� CDOL1 request TSI and TVR



� TVR byte 1, bit 8 = ‘0’ ie Offline Data Authentication was performed




2CI.023.00 Functions not specified in the AIP: Offline StaticData Authentication

Test No. 2CI.023.00

Objective: To ensure that the terminal does not perform Offline Static DataAuthentication if not supported in AIP

Reference: 2RI.019.1 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange Profile: Offline Static Data Authentication

Conditions: � AIP returned by LT specifies that Offline Static Data Authentication is notsupported and Offline Dynamic Data Authentication neither


� Testers will select a payment scheme EMV AID or a generic AID (eg.Non EMV AID) , in the event of payment scheme interference of theEMV functionality



� 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



2CI.024.00 Functions specified in the AIP: Offline DynamicData Authentication

Test No. 2CI.024.00

Objective: To ensure that the terminal performs Offline Dynamic Data Authentication ifsupported in AIP

Reference: 2RI.019.2 - Book 3 Section 4 - Functions specified in the ApplicationInterchange Profile: Offline Dynamic Data Authentication

Conditions: � AIP returned by LT specifies that Offline Dynamic Data Authentication issupported and not Offline Static Data Authentication




� TVR byte 1, bit 8 = ‘0’ ie Offline Data Authentication was performed




2CI.025.00 Functions not specified in the AIP: OfflineDynamic Data Authentication

Test No. 2CI.025.00

Objective: To ensure that the terminal does not perform Offline Dynamic DataAuthentication if not supported in AIP

Reference: 2RI.019.3 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange Profile: Offline Dynamic Data Authentication

Conditions: � AIP returned by LT specifies that Offline Dynamic Data Authentication isnot supported and Offline Static Data Authentication neither





� 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



2CI.026.00 Functions specified in the AIP: Cardholderverification

Test No. 2CI.026.00

Objective: To ensure that the terminal performs Cardholder Verification if supported inAIP

Reference: 2RI.019.4 - Book 3 Section 4 - Functions specified in the ApplicationInterchange Profile: Cardholder verification

Conditions: � AIP returned by LT specifies that Cardholder Verification is supported

� CVM indicates ’Fail CVM, always’




� TVR byte 3, bit 8=’1’ ie Cardholder verification was not successful

� TSI byte 1, bit 7 = ‘1’ ie Cardholder Verification was performed



2CI.027.00 Functions not specified in the AIP: Cardholderverification

Test No. 2CI.027.00

Objective: To ensure that the terminal does not perform Cardholder Verification if notsupported in AIP

Reference: 2RI.019.5 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange Profile: Cardholder verification

Conditions: � AIP returned by LT specifies that Cardholder Verification is notsupported

� CVM is present in LT and indicates ’Fail CVM, always’





� TVR byte 3, bit 8 = ‘0’ ie Cardholder Verification was not failed

� TSI byte 1, bit 7 = ‘0’ ie Cardholder Verification was not performed



2CI.028.00 Functions specified in the AIP: Terminal RiskManagement

Test No. 2CI.028.00

Objective: To ensure that the terminal performs Terminal Risk Management ifsupported in AIP

Reference: 2RI.019.6 - Book 3 Section 4 - Functions specified in the ApplicationInterchange Profile: Terminal Risk Management

Conditions: � Terminal supports Velocity checking

� AIP returned by LT specifies that Terminal Risk Management issupported

� UCOL and LCOL exist in the LT

� Last Online ATC is set to 0 in LT




� TVR byte 2, bit 4 = ‘1’ ie New Card

� TSI byte 1, bit 4 = ‘1’ ie Terminal Risk Management was performed



2CI.029.00 Functions not specified in the AIP: Terminal RiskManagement

Test No. 2CI.029.00

Objective: To ensure that the terminal does not perform Terminal Risk Management ifnot supported in AIP

Reference: 2RI.019.7 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange Profile: Terminal Risk Management

Conditions: � AIP returned by LT specifies that Terminal Risk Management is notsupported

� UCOL and LCOL exists in the LT with 0 value


� Transaction amount above Terminal Floor Limit




� 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



2CI.030.00 Functions specified in the AIP: IssuerAuthentication

Test No. 2CI.030.00

Objective: To ensure that the terminal performs Issuer Authentication if supported inAIP

Reference: 2RI.019.8 - Book 3 Section 4 - Functions specified in the ApplicationInterchange 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 responsemessage

� CDOL2 requests TSI



� The LT shall receive an EXTERNAL AUTHENTICATE commandfollowing the First GENERATE AC

� TSI byte 1, bit 5 = ‘1’ ie Issuer Authentication was performed



2CI.031.00 Functions not specified in the AIP: IssuerAuthentication

Test No. 2CI.031.00

Objective: To ensure that the terminal does not perform Issuer Authentication if notsupported in AIP

Reference: 2RI.019.9 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange 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 responsemessage




� The LT shall not receive an EXTERNAL AUTHENTICATE commandfollowing the First GENERATE AC

� TSI byte 1, bit 5 = ‘0’ ie Issuer Authentication was not performed



2CI.032.00 Exception Handling

Test No. 2CI.032.00

Objective: To ensure that the terminal terminates the transaction in case of statusreturned by the card different from 90 00, 63 Cx, 62 83 unless otherwisespecified 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 bythe Terminal.

Test is performed with several command and with several statusexcept for the following configurations:

� SW1SW2 = '6985' at GPO

� SW1SW2 = '6983' or '6984' or '63Cx' at VERIFY if LT and terminalsupport Offline PIN

� SW1SW2 = any error code at GET DATA requesting PTC if LT andterminal support Offline PIN

� SW1SW2 = any error code at GET DATA requesting ATC and LATC ifLT and terminal support Velocity Checking as Terminal Riskmanagement

� SW1SW2 = 6300 at External Authenticate





2CI.033.00 Functions specified in the ApplicationInterchange Profile: Enhanced Combined DDA / GENERATEAC

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 ApplicationInterchange Profile.

Reference: 2RI.021.0 - Book 3 Section 4 - Functions specified in the ApplicationInterchange Profile: Combined DDA / GENERATE AC

Conditions: � CDOL1 and CDOL2 in ICC includes Unpredictable Number generatedby 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 (inparticular Combined Dynamic Data Authentication).


� TVR and TSI (contained in Batch Data Captured message or other) shallhave

� TVR byte 1, bit 3 = ‘0’ ie Offline Enhanced Combined DDA succeeded




2CI.034.00 Functions not specified in the ApplicationInterchange Profile: Enhanced Combined DDA / GENERATEAC

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 ApplicationInterchange Profile.

Reference: 2RI.021.1 - Book 3 Section 4 - Functions not specified in the ApplicationInterchange Profile: Enhanced Combined DDA / GENERATE AC

Conditions: � CDOL1 and CDOL2 in ICC includes Unpredictable Number generatedby 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


Pass Criteria: � The terminal shall not ask the ICC to process a combined DDA in 1stGenerate AC

� The terminal shall process the transaction until completion.

� TVR and TSI (contained in Batch Data Captured message or other) shallhave

� TSI byte 1, bit 8 = ‘0’ ie Offline Data Authentication was notperformed



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 OPTIONScommand immediately after the application selection function.

Reference: 2RJ.001.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONS commandexecution



Pass Criteria: � LT shall receive a GET PROCESSING OPTIONS command followingfinal 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 thetransaction

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


Pass Criteria: � TSI returned by terminal with GET PROCESSING OPTIONS shall be setto 0b

� TVR returned by terminal with GET PROCESSING OPTIONS shall beset to 0b



2CJ.003.00 GET PROCESSING OPTIONS data field, whenPDOL is provided in FCI

Test No. 2CJ.003.00

Objective: To ensure that if PDOL is present in the FCI of selected ADF, the terminalsends the GET PROCESSING OPTIONS command with a data fieldpopulated with a constructed data object with a tag of ‘83’, a length fieldwith appropriate length and, a value field of concatenated data elementscoded 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 withseveral PDOL values)


Pass Criteria: � LT shall receive a GET PROCESSING OPTIONS command with a datafield containing a data object with Tag ‘83’ and a value field ofconcatenated data elements coded according to the PDOL

2CJ.004.00 GET PROCESSING OPTIONS data field, whenPDOL 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, theterminal sends the GET PROCESSING OPTIONS command with a datafield populated with a constructed data object with a tag of ‘83’, and alength 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


Pass Criteria: � LT shall receive a GET PROCESSING OPTIONS command with a datafield containing a data object with Tag ‘83’ and a length 0



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 itcontains a Data Element which is not defined in Book 1 Annex A DataElements or does not have the terminal as source, the terminal sends aGET PROCESSING OPTIONS command with a PDOL with a DataElement with the length specified and a value of all hexadecimal zeroes forthe tag previously described

Reference: 2RJ.006.0 - Book 3 Section 6.1 - Rules for Processing Tags listed in thePDOL(1)

Conditions: � PDOL is sent back by the LT in FCI of selected ADF and it contains aData Element which is not defined in [N1] or does not have the terminalas source


Pass Criteria: � LT shall receive a GET PROCESSING OPTIONS command with a datafield containing a data object with Tag ‘83’

� Unknown Data Element in PDOL shall be replaced in template ‘83’ witha Data Element with same length and a value of hexadecimal zeroes




Test No. 2CJ.006.00

Objective: To ensure that if PDOL is present in the FCI of selected ADF and if itcontains a Data Element which is a constructed Data Object, the terminalsends a GET PROCESSING OPTIONS command with a PDOL with a DataElement with the length specified and a value of all hexadecimal zeroes forthe tag previously described

Reference: 2RJ.006.1 - Book 3 Section 6.1 - Rules for Processing Tags listed in thePDOL (2)

Conditions: � PDOL is sent back by the LT in FCI of selected ADF and it contains aData Element which is a constructed Data Object



� Constructed Data Object in PDOL shall be replaced in template ‘83’ witha Data Element with same length and a value of hexadecimal zeroes




Test No. 2CJ.007.00

Objective: To ensure that if PDOL is present in the FCI of selected ADF and if itcontains a Data Element which cannot be provided by the terminal at themoment, the terminal sends a GET PROCESSING OPTIONS commandwith a PDOL with a Data Element with the length specified and a value ofall hexadecimal zeroes for the tag previously described

Reference: 2RJ.007.0 - Book 3 Section 6.1 - Rules for Processing Tags listed in thePDOL (3)

Conditions: � PDOL is sent back by the LT in FCI of selected ADF and it contains aData Element which cannot be provided by the terminal at the moment



� Data Object in PDOL which cannot be provided at the moment shall bereplaced in template ‘83’ with a Data Element with same length and avalue of hexadecimal zeroes



2CJ.008.00 GET PROCESSING OPTIONS transaction statemanagement

Test No. 2CJ.008.00

Objective: To ensure that if the card returns status ‘69 85’ to the GET PROCESSINGOPTIONS command, the terminal switches back to the applicationselection phase

Reference: 2RJ.008.0 - Book 3 Section 6.1 - GET PROCESSING OPTIONStransaction state management

Conditions: � LT returns status ‘69 85’ to GET PROCESSING OPTIONS command

� At least 2 applications are mutually supported by LT and Terminal


Pass Criteria: � After having sent status ‘69 85’ in response to GET PROCESSINGOPTIONS, the LT shall receive SELECT command with data fieldcontaining 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 commandsimmediately after the GET PROCESSING OPTIONS command.

Reference: 2RJ.009.0 - Book 3 Section 6.2 - READ RECORD command execution



Pass Criteria: � LT shall receive a sequence of READ RECORD commands immediatelyafter the GET PROCESSING OPTIONS command.



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 READRECORD for each record between the starting record Number and theending 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


Pass Criteria: � The LT shall receive a sequence of READ RECORD commandsaccording 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 ReadApplication 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. ExceptCDOL1 and CDOL2.


Pass Criteria: � The LT shall receive in the GENERATE AC data field, correct values fordata elements stored during the Read Application Data phase



2CJ.012.00 Data objects processing (Unrecognized DataObjects)

Test No. 2CJ.012.00

Objective: To ensure that the terminal ignores unrecognized Data Objects read duringthe Read Application Data phase

Reference: 2RJ.013.1 - Book 3 Section 6.2 - Data objects processing (unrecognisedData Objects)

Conditions: � Records to be read contain non EMV Data Objects





2CJ.012.01 Non recognized data object participating in offlinedata authentication

Test No. 2CJ.012.01

Objective: To ensure that the terminal is able to include non recognized data objectsin offline data authentication provided that they are read with the READRECORD command and are located in record participating in offline dataauthentication according to AFL.

Reference: 2RJ.013.2 - Book 3 Section 6.2 - Non recognized data object participatingin offline data authentication

Conditions: � A non EMV Data Object is included in a record listed in the AFL asparticipating in data authentication


� Signed Static Application Data is good








2CJ.013.00 Record Data Format: mandatory data: ApplicationExpiration Date

Test No. 2CJ.013.00

Objective: To ensure that the terminal terminates the transaction if the ApplicationExpiration 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



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





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 ismissing

Reference: 2RJ.015.2 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data:CDOL1

Conditions: � CDOL1 is missing in LT



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 ismissing

Reference: 2RJ.015.3 - Book 3 Section 6.2 & Book 3 Section 3.1 - Mandatory data:CDOL2

Conditions: � CDOL2 is missing in LT





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 isduplicated

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



2CJ.018.00 Record Data Format: Proprietary dataparticipating in offline data authentication

Test No. 2CJ.018.00

Objective: To ensure that the terminal is able to read and include in Offline dataauthentication, data objects located in proprietary files provided thatproprietary files are readable without conditions by READ RECORDcommand

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


� Signed Static Application Data is good








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 DataAuthentication, the terminal performs Offline Data Authentication at anyorder after the Read Application Data and before completion of the terminalanalysis.

Reference: 2RJ.018.0 - Book 3 Section 6.3 - Offline Data Authentication is supported


� Signed Static Application Data is not good

� IAC denial byte 1 bit 7 = ‘1’, Offline Static Data Authentication failed



Pass Criteria: � The terminal issue a first GENERATE AC requesting AAC




2CJ.021.00 Both the Terminal and the Card support EnhancedCombined DDA/AC (TC, 1st Generate AC)

Test No. 2CJ.021.00

Objective: To ensure that if both the card and the terminal support EnhancedCombined DDA/AC, the terminal performs Enhanced Combined DDA/AC.


Conditions: � Terminal and LT support Enhanced Combined DDA/AC

� CDOL1 and CDOL2 include Unpredictable Number generated by theterminal (tag 9F 37)

� LT answers TC at 1st Generate AC

� Enhanced Combined DDA/AC Generation signature generated by LT isgood








2CJ.021.01 Both the Terminal and the Card support EnhancedCombined DDA/AC (TC, 2nd Generate AC)

Test No. 2CJ.021.01





� LT answers ARQC at 1st Generate AC and TC at 2nd Generate AC









2CJ.021.02 Both the Terminal and the Card support EnhancedCombined DDA/AC (ARQC)

Test No. 2CJ.021.02





� LT answers ARQC at 1st Generate AC









2CJ.022.00 Both the Terminal and the Card support OfflineSDA

Test No. 2CJ.022.00

Objective: To ensure that if both the card and the terminal support Offline Static DataAuthentication, and either terminal or card does not support OfflineDynamic Data Authentication, and either the card or terminal (or both) doesnot support Enhanced Combined DDA/AC Generation, the terminalperforms Offline 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



� TVR byte 1, bit 7 = ‘1’ i.e. Offline Static Data Authentication failed




2CJ.023.00 Both the Offline DDA and the Offline SDA aresupported

Test No. 2CJ.023.00

Objective: To ensure that if both the card and the terminal support Offline Static DataAuthentication, and Offline Dynamic Data Authentication, and either thecard or terminal (or both) does not support Enhanced Combined DDA/ACGeneration, the terminal performs only Offline Dynamic DataAuthentication.


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





� TVR byte 1, bit 7 = ‘0’ i.e. Offline Static Data Authentication was notfailed

� TVR byte 1, bit 4 = ‘1’ i.e. Offline Dynamic Data Authentication failed




2CJ.024.00 Neither the Offline DDA nor the Offline SDA northe Enhanced Combined DDA/AC is performed

Test No. 2CJ.024.00

Objective: To ensure that if neither Offline Static Data Authentication, or OfflineDynamic Data Authentication or the Enhanced Combined DDA/ACGeneration is performed, the terminal sets the ‘Offline data authenticationwas not performed’ bit in the TVR to 1b.


Conditions: � LT and/or Terminal do not support Static Data Authentication

� LT and/or Terminal do not support Dynamic Data Authentication





� 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 notperformed.



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, theterminal concatenate the data retrieved from the records identified by theAFL, with the data from the Static Data Authentication Tag List and usesthe 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








2CJ.026.00 Rules for Processing the records identified by theAFL, when the Offline DDA is performed (1)

Test No. 2CJ.026.00

Objective: To ensure that when terminal performs Dynamic Data Authentication andbuilds the string to be signed, the terminal does not include tag 70 andlength for records referenced in AFL as participating in Dynamic DataAuthentication and located in files with SFI in range 1 to 10

Reference: 2RJ.025.0 - Book 3 Section 6.3 - Rules for Processing the recordsidentified by the AFL, when the Offline DDA is performed (1)

Conditions: � LT and terminal support Dynamic Data Authentication


� some records participating in Dynamic Data Authentication are located infile with SFI in range 1 to 10

� Dynamic signature generated by the LT is good







2CJ.027.00 Rules for Processing the records identified by theAFL, when the Offline DDA is performed (2)

Test No. 2CJ.027.00

Objective: To ensure that when terminal performs Dynamic Data Authentication andbuilds the string to be signed, the terminal includes all data of recordsreferenced in AFL as participating in Dynamic Data Authentication andlocated in files with SFI in range 11 to 30.

Reference: 2RJ.026.0 - Book 3 Section 6.3 - Rules for Processing the recordsidentified by the AFL, when the Offline DDA is performed (2)

Conditions: � LT and terminal support Dynamic Data Authentication


� some records participating in Dynamic Data Authentication are located infile with SFI in range 11 to 30

� Dynamic signature generated by the LT is good







2CJ.028.00 Rules for Processing the records identified by theAFL, when the Offline SDA is performed (1)

Test No. 2CJ.028.00

Objective: To ensure that when terminal performs Static Data Authentication andbuilds the string to be signed, the terminal does not include tag 70 andlength for records referenced in AFL as participating in Static DataAuthentication and located in files with SFI in range 1 to 10

Reference: 2RJ.028.0 - Book 3 Section 6.3 - Rules for Processing the recordsidentified by the AFL, when the Offline SDA is performed (1)

Conditions: � LT and terminal support Static Data Authentication


� some records participating in Static Data Authentication are located infile with SFI in range 1 to 10

� Static signature in the LT is good







2CJ.029.00 Rules for Processing the records identified by theAFL, when the Offline SDA is performed (2)

Test No. 2CJ.029.00

Objective: To ensure that when terminal performs Static Data Authentication andbuilds the string to be signed, the terminal includes all data of recordsreferenced in AFL as participating in Static Data Authentication and locatedin files with SFI in range 11 to 30

Reference: 2RJ.029.0 - Book 3 Section 6.3 - Rules for Processing the recordsidentified by the AFL, when the Offline SDA is performed (2)



� some records participating in Static Data Authentication are located infile with SFI in range 11 to 30

� Static signature in the LT is good







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 butunsuccessful

Reference: 2RJ.032.0 - Book 3 Section 6.3 - Offline Static Data Authentication fails

Conditions: � Signed Static Application Data in LT is not good








2CJ.033.00 Offline Dynamic Data Authentication fails

Test No. 2CJ.033.00

Objective: To ensure that the terminal set the ‘Offline Dynamic Data Authenticationfailed’ bit in the TVR to 1b if the Dynamic Data Authentication is performedbut 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








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 isperformed but unsuccessful



� Enhanced Combined DDA/AC signature generated in LT is failed






� TSI byte 1, bit 8=’1’ i.e. Offline data authentication was performed.



2CJ.034.00 Set relevant bit in TSI, upon completion of theOffline Data Authentication

Test No. 2CJ.034.00

Objective: To ensure that the terminal sets the ‘Offline data authentication wasperformed’ bit in the TSI to 1b upon completion of the Offline DataAuthentication

Reference: 2RJ.034.0 - Book 3 Section 6.3 - Set relevant bit in TSI, upon completion ofthe Offline Data Authentication



� Signed Static Application Data in LT is not good




� TVR byte 1, bit 7=’1’ ie Offline static data authentication failed



2CJ.035.00 Processing Restrictions function execution

Test No. 2CJ.035.00

Objective: To ensure that the terminal performs processing restrictions functions atany time after Read Application Data and before completion of the terminalaction analysis.

Reference: 2RJ.035.0 - Book 3 Section 6.4 - Processing Restrictions functionexecution

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




� TVR byte 2, bit 8 = ‘1’ ie ICC and Terminal have different applicationversions

� TVR byte 2, bit 5 = ‘1’ ie Requested service not allowed for card product

� TVR byte 2, bit 7 = ‘1’ ie Expired application



2CJ.036.00 Application Version Number assigned by thepayment system

Test No. 2CJ.036.00

Objective: To ensure that the terminal maintains an Application Version Numberassigned by the payment system.

Reference: 2RJ.036.0 - Book 3 Section 6.4.1 - Application Version Number assignedby the payment system

Conditions: � CDOL1 requests Application Version Number (9F 09)

� Test is made for all applications supported by the terminal



� LT shall received the value of application version number for theselected application



2CJ.037.00 Application Version Number is not present in theICC

Test No. 2CJ.037.00

Objective: To ensure that the terminal continues the processing of the transaction untilthe 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 notpresent in the ICC

Conditions: � Application Version Number is not present in the ICC




� The terminal shall presume applications are compatible between ICCand terminal

� TVR byte 2, bit 8 = ‘0’ ie ICC and terminal does not have differentapplication versions



2CJ.039.00 Application Version Number present in the ICCand 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 havedifferent application versions’ bit in the TVR to 1b if the Application VersionNumber 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 inthe ICC and in the terminal are the same (implied)

Conditions: � LT and terminal have the same Application Version Number




� TVR byte 2, bit 8 = ‘0’ ie ICC and terminal have the same applicationversions



2CJ.041.00 AUC is present in the ICC and Transaction isconducted 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 andTransaction 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







2CJ.042.00 AUC is present in the ICC and Transaction isconducted 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 setthe ‘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 andTransaction is conducted at an ATM (implied)


� Terminal Type is ATM

� ‘Valid at ATMs’ bit is set to 1b in the AUC




� TVR byte 2, bit 5 = ‘0’ ie Requested service allowed for card product



2CJ.043.00 AUC is present in the ICC and Transaction is notconducted 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 thecard, and the ‘Valid at terminals other than ATMs ’ bit is not set to 1b in theAUC, 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 andTransaction is not conducted at an ATM


� Terminal Type is not an ATM

� ‘Valid at terminals other than ATMs’ bit is not set to 1b in the AUC







2CJ.044.00 AUC is present in the ICC and Transaction is notconducted 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 thecard, and the ‘Valid at terminals other than ATMs ’ bit is set to 1b in theAUC, the terminal does not set the ‘Requested service not allowed for cardproduct’ bit in the TVR to 1b.

Reference: 2RJ.043.1 - Book 3 Section 6.4.2 - AUC is present in the ICC andTransaction is not conducted at an ATM (implied)


� Terminal Type is not an ATM

� ‘Valid at terminals other than ATMs’ bit is set to 1b in the AUC







2CJ.045.00 Transaction type is a Cash transaction, and IssuerCountry Code = Terminal Country Code

Test No. 2CJ.045.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a cash transaction and the AUC is presentin the card, and the ‘Valid for domestic cash transactions’ bit is not set to 1bin the AUC, the terminal sets the ‘Requested service not allowed for cardproduct’ 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


� ‘Valid for domestic cash transactions’ bit is not set to 1b in the AUC

� CDOL1 requests TVR and Transaction Type




� Transaction Type shall indicate a cash transaction



2CJ.046.00 Transaction type is a Cash transaction, and IssuerCountry Code = Terminal Country Code (implied)

Test No. 2CJ.046.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a cash transaction and the AUC is presentin the card, and the ‘Valid for domestic cash transactions’ bit is set to 1b inthe AUC, the terminal does not set the ‘Requested service not allowed forcard 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)




� ‘Valid for domestic cash transactions’ bit is set to 1b in the AUC









2CJ.047.00 Transaction type is a Cash transaction, and IssuerCountry Code differs from Terminal Country Code

Test No. 2CJ.047.00

Objective: To ensure that if the Terminal Country Code does not match Issuer CountryCode and Transaction Type indicates a cash transaction and the AUC ispresent in the card, and the ‘Valid for international cash transactions’ bit isnot set to 1b in the AUC, the terminal sets the ‘Requested service notallowed 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



� Issuer Country Code does not match Terminal Country Code

� ‘Valid for international cash transactions’ bit is not set to 1b in the AUC








2CJ.048.00 Transaction type is a Cash transaction, and IssuerCountry 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 CountryCode and Transaction Type indicates a cash transaction and the AUC ispresent in the card, and the ‘Valid for international cash transactions’ bit isset to 1b in the AUC, the terminal does not set the ‘Requested service notallowed 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)




� ‘Valid for international cash transactions’ bit is set to 1b in the AUC









2CJ.049.00 Transaction type is a Purchase of goods, andIssuer Country Code = Terminal Country Code

Test No. 2CJ.049.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a purchase of goods and the AUC ispresent in the card, and the ‘Valid for domestic goods’ bit is not set to 1b inthe AUC, the terminal sets the ‘Requested service not allowed for cardproduct’ bit in the TVR to 1b.

Reference: 2RJ.047.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofgoods, and Issuer Country Code = Terminal Country Code

Conditions: � Transaction is a purchase of goods



� ‘Valid for domestic goods’ bit is not set to 1b in the AUC





� Transaction Type shall indicate a purchase of goods



2CJ.050.00 Transaction type is a Purchase of goods, andIssuer Country Code = Terminal Country Code (implied)

Test No. 2CJ.050.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a purchase of goods and the AUC ispresent in the card, and the ‘Valid for domestic goods’ bit is set to 1b in theAUC, the terminal does not set the ‘Requested service not allowed for cardproduct’ bit in the TVR to 1b.

Reference: 2RJ.047.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofgoods, and Issuer Country Code = Terminal Country Code (implied)




� ‘Valid for domestic goods’ bit is set to 1b in the AUC









2CJ.051.00 Transaction type is a Purchase of goods, andIssuer 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 CountryCode and Transaction Type indicates a purchase of goods and the AUC ispresent in the card, and the ‘Valid for international goods’ bit is not set to 1bin the AUC, the terminal sets the ‘Requested service not allowed for cardproduct’ bit in the TVR to 1b.

Reference: 2RJ.048.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofgoods, and Issuer Country Code differs from Terminal Country Code




� ‘Valid for international goods’ bit is not set to 1b in the AUC








2CJ.052.00 Transaction type is a Purchase of goods, andIssuer 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 CountryCode and Transaction Type indicates a purchase of goods and the AUC ispresent in the card, and the ‘Valid for international goods’ bit is set to 1b inthe AUC, the terminal does not set the ‘Requested service not allowed forcard product’ bit in the TVR to 1b.

Reference: 2RJ.048.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofgoods, and Issuer Country Code differs from Terminal Country Code(implied)




� ‘Valid for international goods’ bit is set to 1b in the AUC









2CJ.053.00 Transaction type is a Purchase of services, andIssuer Country Code = Terminal Country Code

Test No. 2CJ.053.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a purchase of services and the AUC ispresent in the card, and the ‘Valid for domestic services’ bit is not set to 1bin the AUC, the terminal sets the ‘Requested service not allowed for cardproduct’ bit in the TVR to 1b.

Reference: 2RJ.049.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofservices, and Issuer Country Code = Terminal Country Code

Conditions: � Transaction is a purchase of services



� ‘Valid for domestic services’ bit is not set to 1b in the AUC





� Transaction Type shall indicate a purchase of services



2CJ.054.00 Transaction type is a Purchase of services, andIssuer Country Code = Terminal Country Code (implied)

Test No. 2CJ.054.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction Type indicates a purchase of services and the AUC ispresent in the card, and the ‘Valid for domestic services’ bit is set to 1b inthe AUC, the terminal does not set the ‘Requested service not allowed forcard product’ bit in the TVR to 1b.

Reference: 2RJ.049.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofservices, and Issuer Country Code = Terminal Country Code (implied)




� ‘Valid for domestic services’ bit is set to 1b in the AUC









2CJ.055.00 Transaction type is a Purchase of services, andIssuer 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 CountryCode and Transaction Type indicates a purchase of services and the AUCis present in the card, and the ‘Valid for international services’ bit is not setto 1b in the AUC, the terminal sets the ‘Requested service not allowed forcard product’ bit in the TVR to 1b.

Reference: 2RJ.050.0 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofservices, and Issuer Country Code differs from Terminal Country Code




� ‘Valid for international services’ bit is not set to 1b in the AUC








2CJ.056.00 Transaction type is a Purchase of services, andIssuer 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 CountryCode and Transaction Type indicates a purchase of services and the AUCis present in the card, and the ‘Valid for international services’ bit is set to1b in the AUC, the terminal does not set the ‘Requested service not allowedfor card product’ bit in the TVR to 1b.

Reference: 2RJ.050.1 - Book 3 Section 6.4.2 - Transaction type is a Purchase ofservices, and Issuer Country Code differs from Terminal Country Code(implied)




� ‘Valid for international services’ bit is set to 1b in the AUC









2CJ.057.00 Transaction has a Cashback amount, and IssuerCountry Code = Terminal Country Code

Test No. 2CJ.057.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction has a Cashback amount and the AUC is present in thecard, 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 inthe 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



� ‘Domestic cashback allowed’ bit is not set to 1b in the AUC







2CJ.058.00 Transaction has a Cashback amount, and IssuerCountry Code = Terminal Country Code (implied)

Test No. 2CJ.058.00

Objective: To ensure that if the Terminal Country Code matches Issuer Country Codeand Transaction has a Cashback amount and the AUC is present in thecard, and the ‘Domestic cashback allowed’ bit is set to 1b in the AUC, theterminal 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)




� ‘Domestic cashback allowed’ bit is set to 1b in the AUC








2CJ.059.00 Transaction type is a Cashback amount, andIssuer 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 CountryCode and Transaction has a Cashback amount and the AUC is present inthe card, and the ‘International cashback allowed’ bit is not set to 1b in theAUC, 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




� ‘International cashback allowed’ bit is not set to 1b in the AUC







2CJ.060.00 Transaction type is a Cashback amount, andIssuer 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 CountryCode and Transaction has a Cashback amount and the AUC is present inthe card, and the ‘International cashback allowed’ bit is set to 1b in theAUC, the terminal does not set the ‘Requested service not allowed for cardproduct’ 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)




� ‘International cashback allowed’ bit is set to 1b in the AUC








2CJ.061.00 Application Usage Control is not present in theICC (implied)

Test No. 2CJ.061.00

Objective: To ensure that if the Application Usage control is not present in the ICC, theTerminal 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 presentin the ICC implied

Conditions: � AUC is not present in LT








2CJ.062.00 Application Usage Control is present in the ICCbut 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 notIssuer Country Code, the Terminal skips the second set of tests describedin Book 3 Section 6.4.3.

Reference: 2RJ.053.1 - Book 3 Section 6.4.2 - Application Usage Control is present inthe ICC but not Issuer Country code (implied)


� ‘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 theEMV functionality CDOL1 requests TVR






2CJ.063.00 Current Date is less than Application EffectiveDate

Test No. 2CJ.063.00

Objective: To ensure that the terminal sets to 1b the ‘Application not yet effective’ bit ifthe current date is less than the Application Effective Date

Reference: 2RJ.055.0 - Book 3 Section 6.4.3 - Current Date is less than ApplicationEffective Date

Conditions: � Application Effective Date is present in the LT

� current date is less than the Application Effective Date



� TVR byte 2, bit 6 = ‘1’ ie Application not yet effective



2CJ.064.00 Current Date is greater than Application EffectiveDate (implied)

Test No. 2CJ.064.00

Objective: To ensure that the terminal does not set to 1b the ‘Application not yeteffective’ bit if the current date is greater or equal to the ApplicationEffective Date

Reference: 2RJ.055.1 - Book 3 Section 6.4.3 - Current Date is greater than ApplicationEffective Date (implied)


� Current date is greater than the Application Effective Date

� CDOL1 requested TVR




� TVR byte 2, bit 6 = ‘0’ ie Application effective



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 yeteffective’ bit if the current date is greater or equal to the ApplicationEffective Date

Reference: 2RJ.055.2 - Book 3 Section 6.4.3 - Current Date is equal to ApplicationEffective Date (implied)


� Current data is equal to the Application Effective Date








2CJ.065.00 Current Date is greater than ApplicationExpiration Date

Test No. 2CJ.065.00

Objective: To ensure that the terminal sets to 1b the ‘expired Application’ bit if thecurrent date is greater than the Application Expiration Date

Reference: 2RJ.056.0 - Book 3 Section 6.4.3 - Current Date is greater than ApplicationExpiration Date

Conditions: � current date is greater than the Application Expiration Date




� TVR byte 2, bit 7 = ‘1’ ie expired Application

2CJ.066.00 Current Date is less than Application ExpirationDate (implied)

Test No. 2CJ.066.00

Objective: To ensure that the terminal does not set to 1b the ‘expired Application’ bit ifthe 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 ApplicationExpiration Date (implied)

Conditions: � Current date is less than the Application Expiration Date

� CDOL1 requested TVR to be present




� TVR byte 2, bit 7 = ‘0’ ie non expired Application



2CJ.066.01 Current Date is equal to the Application ExpirationDate (implied)

Test No. 2CJ.066.01

Objective: To ensure that the terminal does not set to 1b the ‘expired Application’ bit ifthe 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 ApplicationExpiration Date (implied)

Conditions: � Current date is equal to the Application Expiration Date





� TVR byte 2, bit 7 = ‘0’ ie non expired Application



2CJ.067.00 Application Effective Date is not present in theICC (implied)

Test No. 2CJ.067.00

Objective: To ensure that the terminal does not set to 1b the ‘Application not yeteffective’ 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 presentin the ICC (implied)

Conditions: � Application Effective Date is not present in the LT








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 terminalperforms Cardholder verification after the Read Application Data and beforecompletion of the terminal analysis

Reference: 2RJ.058.0 - Book 3 Section 6.5 - Cardholder Verification is supported in theApplication Interchange Profile

Conditions: � LT supports Cardholder verification

� CVM in LT is 'Fail CVM, always'




� 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


� CVM in LT is 'Fail CVM, always’







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 orCashback


� Transaction Type is cash

� CVM in LT is 'Fail CVM, if Cash or Cashback’







2CJ.071.00 Supported CVR condition: If not Cash orCashback

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 orCashback


� 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 Authorisedand Amount Other






2CJ.073.00 Supported CVR condition: If Terminal supportsthe CVM and CVM is offline PIN

Test No. 2CJ.073.00

Objective: To ensure that terminal supports CVM condition ‘If Terminal supports theCVM’ when CVM is offline PIN

Reference: 2RJ.059.4 - Book 3 Section 6.5 - Supported CVR condition: If Terminalsupports the CVM and CVM is offline PIN


� Terminal supports Offline PIN

� CVM in LT is 'Plaintext PIN verification performed by ICC, if Terminalsupports the CVM'

� PIN presented is not good or PIN try Counter is 0







2CJ.074.00 Supported CVR condition: If Terminal supportsthe CVM and CVM is online PIN

Test No. 2CJ.074.00

Objective: To ensure that terminal supports CVM condition ‘If Terminal supports theCVM’ when CVM is online PIN

Reference: 2RJ.059.5 - Book 3 Section 6.5 - Supported CVR condition: If Terminalsupports 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 Terminalsupports the CVM'

� PIN entered




� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification successful.

� Encrypted PIN Data is sent in the Authorization Request.



2CJ.075.00 Supported CVR condition: If Terminal supportsthe CVM and CVM is signature

Test No. 2CJ.075.00

Objective: To ensure that terminal supports CVM condition ‘If Terminal supports theCVM’ when CVM is signature

Reference: 2RJ.059.6 - Book 3 Section 6.5 - Supported CVR condition: If Terminalsupports the CVM and CVM is signature


� Terminal supports signature

� CVM in LT is 'signature, if Terminal supports the CVM'

� CDOL1 requests CVM Results



� CVM Results shall be set to “1E 03 00’’



2CJ.077.00 Supported CVR condition: If Transaction is in theapplication currency and is under X value when thetransaction amount is less than X

Test No. 2CJ.077.00

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is under X value” when the transaction amount isless than X

Reference: 2RJ.059.8 - Book 3 Section 6.5 - Supported CVR condition: "If Transactionis in the application currency and is under X" (1) (Transaction Amount isLess than X)


� 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






2CJ.077.01 Supported CVR condition: If Transaction is in theapplication currency and is under X value when thetransaction amount is greater than X

Test No. 2CJ.077.01

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is under X value” when the transaction amount isGreater than X

Reference: 2RJ.059.81 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is under X" (2) (TransactionAmount is Greater than X)


� CVM in LT is 'Fail CVM, if Transaction is under X' followed by Fail CVM,always'

� Transaction amount is greater than X value


� CDOL1 request TVR and CVM Results




� CVM Results show 'Fail CVM, always, process is failed' as the last CVMprocessed ('00 00 01')



2CJ.077.02 Supported CVR condition: If Transaction is in theapplication currency and is under X value when thetransaction amount is equal to X

Test No. 2CJ.077.02

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is under X value” when the transaction amount isEqual to X

Reference: 2RJ.059.82 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is under X" (3) (TransactionAmount is Equal to X)


� CVM in LT is 'Fail CVM, if Transaction is under X' followed by 'Fail CVM,always'

� Transaction amount is equal to X value


� CDOL1 request TVR and CVM results







2CJ.078.00 Supported CVR condition: If Transaction is in theapplication currency and is over X value when transactionamount is greater than X.

Test No. 2CJ.078.00

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is over X value” when transaction amount isgreater than X.

Reference: 2RJ.059.9 - Book 3 Section 6.5 - Supported CVR condition: "If Transactionis in the application currency and is over X" (1) (Transaction amount isgreater than X).


� CVM in LT is 'Fail CVM, if Transaction is over X'

� Transaction amount is greater than X value








2CJ.078.01 Supported CVR condition: If Transaction is in theapplication currency and is over X value when transactionamount is less than X.

Test No. 2CJ.078.01

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is over X value” when transaction amount is lessthan X.

Reference: 2RJ.059.91 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is over X" (2) (TransactionAmount is Less than X)


� CVM in LT is 'Fail CVM, if Transaction is over X' followed by 'Fail CVM,always'

� Transaction amount is less than X value









2CJ.078.02 Supported CVR condition: If Transaction is in theapplication currency and is over X value when transactionamount is equal to X.

Test No. 2CJ.078.02

Objective: To ensure that terminal supports CVM condition ”If Transaction is in theapplication currency and is over X value” when transaction amount is Equalto X.

Reference: 2RJ.059.92 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is over X" (3) (TransactionAmount is Equal to X)


� CVM in LT is 'Fail CVM, if Transaction is over X' followed by 'Fail CVM,always'

� Transaction amount is equal to X value









2CJ.079.00 Supported CVR condition: If Transaction is in theapplication currency and is under Y value when thetransaction amount is less than Y.

Test No. 2CJ.079.00

Objective: To ensure that terminal supports CVM condition ‘If Transaction is in theapplication currency and is under Y value’ when the transaction amount isless than Y.

Reference: 2RJ.059.10 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is under Y" (1) (Transactionamount is less than Y).


� CVM in LT is 'Fail CVM, if Transaction is under Y'

� Transaction amount is less than Y value








2CJ.079.01 Supported CVR condition: If Transaction is in theapplication currency and is under Y value when thetransaction amount is greater than Y

Test No. 2CJ.079.01

Objective: To ensure that terminal supports CVM condition ‘If Transaction is in theapplication currency and is under Y value’ when the transaction amount isGreater than Y.

Reference: 2RJ.059.12 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is under Y" (2) (Transactionamount is greater than Y)


� CVM in LT is 'Fail CVM if Transaction is under Y' followed by 'Fail CVM,always'

� Transaction amount is greater than Y value









2CJ.079.02 Supported CVR condition: If Transaction is in the applicationcurrency 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 theapplication currency and is under Y value’ when the transaction amount isEqual to Y.

Reference: 2RJ.059.13 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is under Y" (3) (Transactionamount is equal to Y)


� CVM in LT is 'Fail CVM, if Transaction is under Y' followed by 'Fail CVM,always'

� Transaction amount is equal to Y value






�




2CJ.080.00 Supported CVR condition: If Transaction is in theapplication currency and is over Y value when the transactionamount is greater than Y.

Test No. 2CJ.080.00

Objective: To ensure that terminal supports CVM condition ‘If Transaction is in theapplication currency and is over Y value’ when the transaction amount isgreater than Y.

Reference: 2RJ.059.11 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is over Y" (1) (Transactionamount is Greater than Y).


� CVM in LT is 'Fail CVM, if Transaction is over Y'

� Transaction amount is greater than Y value








2CJ.080.01 Supported CVR condition: If Transaction is in theapplication currency and is over Y value when the transactionamount is equal to Y.

Test No. 2CJ.080.01

Objective: To ensure that terminal supports CVM condition ‘If Transaction is in theapplication currency and is over Y value’ when the transaction amount isequal to Y.

Reference: 2RJ.059.14 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is over Y" (2) (Transactionamount is Equal to Y)

Conditions:

� LT supports Cardholder verification

� CVM in LT is 'Fail CVM, if Transaction is over Y' followed by 'Fail CVMalways'

� Transaction amount is equal to Y value









2CJ.080.02 Supported CVR condition: If Transaction is in theapplication currency and is over Y value when the transactionamount is less than Y.

Test No. 2CJ.080.02

Objective: To ensure that terminal supports CVM condition ‘If Transaction is in theapplication currency and is over Y value’ when the transaction amount isless than Y.

Reference: 2RJ.059.15 - Book 3 Section 6.5 - Supported CVR condition: "IfTransaction is in the application currency and is over Y" (3) (Transactionamount is Less than Y)


� CVM in LT is 'Fail CVM, if Transaction is over Y' followed by 'Fail CVMalways'

� Transaction amount is less than Y value









2CJ.081.01 Random Transaction Selection: TransactionAmount Less than the Threshold Value for Biased RandomSelection

Test No. 2CJ.081.01

Objective: To ensure that terminal performs Random Transaction Selection checkingwhen the transaction amount is less than the Threshold Value for BiasedRandom Selection

Reference: 2RJ.093.1 - Book 3 Section 6.6.2 - Transaction Amount < Threshold Valueand Random Number � Target Percentage

Conditions: � Terminal supports Random Transaction Selection


� Transaction Amount is less than the Threshold Value for BiasedRandom Selection

� Random Number is less than or equal to Target Percentage to be Usedfor Random Selection (Test must be repeated until this condition is met)




� TVR byte 4, bit 5 = ‘1’ ie Transaction selected randomly for onlineprocessing



2CJ.081.02 Random Transaction Selection: TransactionAmount Less than the Threshold Value for Biased RandomSelection

Test No. 2CJ.081.02

Objective: To ensure that terminal performs Random Transaction Selection checkingwhen the transaction amount is less than the Threshold Value for BiasedRandom Selection

Reference: 2RJ.093. 2 - Book 3 Section 6.6.2 - Transaction Amount < Threshold Valueand Random Number > Target Percentage



� Transaction Amount is less than the Threshold Value for BiasedRandom Selection

� Random Number is greater than the Target Percentage to be Used forRandom Selection (Test must be repeated until this condition is met)




� TVR byte 4, bit 5 = ‘0’ ie Transaction has not been selected randomly foronline processing



2CJ.081.03 Random Transaction Selection: TransactionAmount Equal to or Greater than the Threshold Value forBiased Random Selection but Less than the Floor Limit

Test No. 2CJ.081.03

Objective: To ensure that terminal performs Random Transaction Selection checkingwhen the transaction amount is equal to or greater than the ThresholdValue 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



� Transaction Amount is equal to or greater than the Threshold Value forBiased 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)




� TVR byte 4, bit 5 = ‘1’ ie Transaction selected randomly for onlineprocessing



2CJ.081.04 Random Transaction Selection: TransactionAmount Equal to or Greater than the Threshold Value forBiased Random Selection but Less than the Floor Limit

Test No. 2CJ.081.04

Objective: To ensure that terminal performs Random Transaction Selection checkingwhen the transaction amount is equal to or greater than the ThresholdValue 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



� Transaction Amount is equal to or greater than the Threshold Value forBiased 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)




� TVR byte 4, bit 5 = ‘0’ ie Transaction has not been selected randomly foronline processing



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 wasperformed’ 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


� CVM is not present in the LT




� 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 processeseach rule in the order in which it appears in the CVM List, until thecardholder verification is completed.

Reference: 2RJ.060.1 - Book 3 Section 6.5 - CVM List is present in the ICC


� At least two CVM List are tested with several entries




� TVR byte 3, bit 8 shall be set in accordance with CVM List and results ofprocessing



2CJ.083.00 Second byte of a Cardholder Verification Rule isnot satisfied

Test No. 2CJ.083.00

Objective: To ensure that if the conditions expressed in the second byte of aCardholder Verification Rule are not satisfied, the terminal bypasses therules and proceeded to the next rule.

Reference: 2RJ.061.0 - Book 3 Section 6.5 - Second byte of a Cardholder VerificationRule is not satisfied


� CVM List is 'No CVM required, if transaction is under X' followed by 'FailCVM, always'

� X is such as Transaction amount is over X







2CJ.083.01 Non Supported CVR condition: If Terminalsupports 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 CVMcondition ‘If Terminal supports the CVM’ when CVM is offline PIN and theterminal does not support offline Plaintext PIN



� Terminal does not support Offline Plaintext PIN

� CVM in LT is 'Plaintext PIN verification performed by ICC if Terminalsupports the CVM' ('01 03') followed by 'Fail CVM, always' ('00 00')

� CDOL1 requests TVR and CVM Results




� CVM Results show 'Fail CVM, always, process is failed' as the last CVMprocessed (00 00 01')



2CJ.083.02 Non Supported CVR condition: If Terminalsupports 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 CVMcondition ‘If Terminal supports the CVM’ when CVM is offline PIN and theterminal does not support offline Enciphered PIN



� Terminal does not support Offline Enciphered PIN

� CVM in LT is 'Offline Enciphered PIN verification performed by ICC ifTerminal supports the CVM' ('04 03') followed by 'Fail CVM, always' ('0000')








2CJ.083.03 Non Supported CVR condition: If Terminalsupports 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 CVMcondition ‘If Terminal supports the CVM’ when CVM is online PIN and theterminal does not support online Enciphered PIN



� Terminal does not support Online Enciphered PIN

� CVM in LT is 'Online Enciphered PIN verification performed by ICC ifTerminal supports the CVM' ('02 03') followed by 'Fail CVM, always' ('0000')








2CJ.083.04 Non Supported CVR condition: If Terminalsupports 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 CVMcondition ‘If Terminal supports the CVM’ when CVM is Signature and theterminal does not support Signature



� Terminal does not support Signature

� CVM in LT is 'Signature if Terminal supports the CVM' ('1E 03') followedby 'Fail CVM, always' ('00 00')








2CJ.083.05 Non Supported CVR condition: If Terminalsupports the CVM and CVM is offline Plaintext PIN andSignature

Test No. 2CJ.083.05

Objective: To ensure that terminal processes the next CVM in the list when the CVMcondition ‘If Terminal supports the CVM’ when CVM is offline Plaintext PINand Signature and the terminal does not support offline Plaintext PIN orSignature



� Terminal does not support Offline Plaintext PIN or Signature

� CVM in LT is 'Offline Plaintext PIN verification performed by ICC andSignature if Terminal supports the CVM' ('03 03') followed by 'Fail CVM,always' ('00 00')








2CJ.083.06 Non Supported CVR condition: If Terminalsupports the CVM and CVM is offline Enciphered PIN andSignature

Test No. 2CJ.083.06

Objective: To ensure that terminal processes the next CVM in the list when the CVMcondition ‘If Terminal supports the CVM’ when CVM is offline EncipheredPIN and Signature and the terminal does not support offline EncipheredPIN or Signature



� Terminal does not support Offline Enciphered PIN or Signature

� CVM in LT is 'Offline Enciphered PIN verification performed by ICC andSignature if Terminal supports the CVM' ('05 03') followed by 'Fail CVM,always' ('00 00')








2CJ.083.07 No Supported CVR condition: If Terminalsupports 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 CVMcondition ‘If Terminal supports the CVM’ when CVM is 'No CVM Required'and the terminal does not support 'No CVM Required'



� 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')








2CJ.084.00 ICC Data required by the CVM Condition Code ismissing

Test No. 2CJ.084.00

Objective: To ensure that if the ICC data required by the condition expressed in thesecond byte of a Cardholder Verification Rule is not present, the terminalbypasses the rules and proceeded to the next rule.

Reference: 2RJ.061.1 - Book 3 Section 6.5 - ICC Data required by the CVM ConditionCode is missing


� CVM List is Fail CVM if transaction is in the application currency and isunder X' followed by 'Fail CVM, always'

� Application Currency Code is not present in the LT

� X is such as Transaction amount is under X








2CJ.085.00 CVM Condition Code is outside the range ofcodes understood by the terminal

Test No. 2CJ.085.00

Objective: To ensure that if the condition code expressed in the second byte of aCardholder Verification Rule is outside the range of codes understood bythe terminal, the terminal bypasses the rules and proceeded to the nextrule.

Reference: 2RJ.061.2 - Book 3 Section 6.5 - CVM Condition Code is outside the rangeof codes understood by the terminal


� CVM List is Fail CVM , if RFU' following by 'Fail CVM, always'








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 notsuccessful’ bit if the list of CVM is exhausted and Cardholder Verificationhas not been successful

Reference: 2RJ.062.0 - Book 3 Section 6.5 - Cardholder Verification is not successful


� 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







2CJ.087.00 Second byte of Cardholder Verification Rulesatisfied and CVM Code is Fail CVM

Test No. 2CJ.087.00

Objective: To ensure that the terminal performs the CVM if the condition code issatisfied and CVM code is fail CVM

Reference: 2RJ.063.0 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Fail CVM


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








2CJ.088.00 Second byte of CVR satisfied and CVM Code isPlain text PIN verified by ICC (Plain text PIN verified by ICCsupported)

Test No. 2CJ.088.00

Objective: To ensure that if terminal supports Plaintext PIN verified by ICC, theterminal performs the CVM if the condition code is satisfied and CVM codeis Plaintext PIN verified by ICC

Reference: 2RJ.063.1 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Plaintext PIN verified by ICC (Plain textPIN verified by ICC supported)


� CVM List is 'Plaintext PIN verified by ICC' with a satisfied condition ie

* always or




� Terminal supports Plaintext PIN verified by ICC

� Supported PIN presented is not good





� Terminal shall ask the cardholder to present his PIN




2CJ.088.01 Second byte of CVR satisfied and CVM Code isPlain text PIN verified by ICC (Plain text PIN verified by ICC notsupported)

Test No. 2CJ.088.01

Objective: To ensure that if the terminal does not support Plaintext PIN verified byICC, the terminal performs the CVM if the condition code is satisfied andCVM code is Plaintext PIN verified by ICC

Reference: 2RJ.063.11 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Plaintext PIN verified by ICC (Plain textPIN verified by ICC not supported)


� CVM List is 'Plaintext PIN verified by ICC' with a satisfied condition ie

* always or




� Terminal does not support Plaintext PIN verified by ICC




� 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



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 terminalperforms the CVM if the condition code is satisfied and CVM code isEnciphered PIN Online

Reference: 2RJ.063.2 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Enciphered PIN Online (Enciphered PINOnline supported)


� Terminal supports Online verification

� CVM List is 'Enciphered PIN online' with a satisfied condition ie

* always or




� Terminal supports Enciphered PIN online

� PIN is entered




� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification success


� Encrypted PIN Data is sent in the Authorization Request.




2CJ.089.01 Second byte of CVR satisfied and CVM Code isEnciphered 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, theterminal performs the CVM if the condition code is satisfied and CVM codeis Enciphered PIN Online

Reference: 2RJ.063.21 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Enciphered PIN Online (Enciphered PINOnline not supported)


� Terminal supports Online verification

� CVM List is 'Enciphered PIN online' with a satisfied condition ie

* always or




� Terminal does not support Enciphered PIN online





� TVR byte 3, bit 5 = ‘1’ ie PIN entry required and PIN pad not present




2CJ.090.00 Second byte of CVR satisfied and CVM Code isPlain text PIN verified by ICC and signature (Plain text PINverified by ICC and signature supported)

Test No. 2CJ.090.00

Objective: To ensure that if terminal supports Plaintext PIN verified by ICC andsignature, the terminal performs the CVM if the condition code is satisfiedand CVM code is Plaintext PIN verified by ICC and signature

Reference: 2RJ.063.3 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Plaintext PIN verified by ICC and signature(Plain text PIN verified by ICC and signature supported)


� CVM List is 'Plaintext PIN verified by ICC and signature' with a satisfiedcondition ie

* always or




� Terminal supports Plaintext PIN verified by ICC










2CJ.090.01 Second byte of CVR satisfied and CVM Code isPlain text PIN verified by ICC and signature (Plain text PINverified 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 ICCand signature, the terminal performs the CVM if the condition code issatisfied and CVM code is Plaintext PIN verified by ICC and signature

Reference: 2RJ.063.31 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Plaintext PIN verified by ICC and signature(Plain text PIN verified by ICC and signature not supported)


� CVM List is 'Plaintext PIN verified by ICC and signature' with a satisfiedcondition ie

* always or




� Terminal does not support Plaintext PIN verified by ICC








2CJ.091.00 Second byte of CVR satisfied and CVM Code isEnciphered PIN verified by ICC (Enciphered PIN verified by ICCsupported)

Test No. 2CJ.091.00

Objective: To ensure that if terminal supports Enciphered PIN verified by ICC, theterminal performs the CVM if the condition code is satisfied and CVM codeis Enciphered PIN verified by ICC

Reference: 2RJ.063.4 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Enciphered PIN verified by ICC(Enciphered PIN verified by ICC supported)


� CVM List is 'Enciphered PIN verified by ICC' with a satisfied condition ie

* always or




� Terminal supports Enciphered PIN verified by ICC










2CJ.091.01 Second byte of CVR satisfied and CVM Code isEnciphered PIN verified by ICC (Enciphered PIN verified by ICCnot supported)

Test No. 2CJ.091.01

Objective: To ensure that if the terminal does not support Enciphered PIN verified byICC, the terminal performs the CVM if the condition code is satisfied andCVM code is Enciphered PIN verified by ICC

Reference: 2RJ.063.41 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is Enciphered PIN verified by ICC(Enciphered PIN verified by ICC not supported)


� CVM List is 'Enciphered PIN verified by ICC' with a satisfied condition ie

* always or




� Terminal does not support Enciphered PIN verified by ICC





�




2CJ.092.00 Second byte of CVR satisfied and CVM CodeEnciphered PIN verified by ICC and signature (Enciphered PINverified by ICC and signature supported)

Test No. 2CJ.092.00

Objective: To ensure that if terminal supports Enciphered PIN verified by ICC andsignature, the terminal performs the CVM if the condition code is satisfiedand CVM code is Enciphered PIN verified by ICC and signature

Reference: 2RJ.063.5 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code Enciphered PIN verified by ICC andsignature (Enciphered PIN verified by ICC and signature supported)


� CVM List is 'Enciphered PIN verified by ICC and signature' with asatisfied condition ie

* always or




� Terminal supports Enciphered PIN verified by ICC










2CJ.092.01 Second byte of CVR satisfied and CVM CodeEnciphered PIN verified by ICC and signature (Enciphered PINverified by ICC and signature not supported)

Test No. 2CJ.092.01

Objective: To ensure that if the terminal does not support Enciphered PIN verified byICC and signature, the terminal performs the CVM if the condition code issatisfied and CVM code is Enciphered PIN verified by ICC and signature

Reference: 2RJ.063.51 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code Enciphered PIN verified by ICC andsignature (Enciphered PIN verified by ICC and signature not supported)


� CVM List is 'Enciphered PIN verified by ICC and signature' with asatisfied condition ie

* always or




� Terminal does not support Enciphered PIN verified by ICC and signature









2CJ.093.00 Second byte of CVR satisfied and CVM Code issignature (signature supported)

Test No. 2CJ.093.00

Objective: To ensure that if terminal supports signature, the terminal performs theCVM if the condition code is satisfied and CVM code is signature

Reference: 2RJ.063.6 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is signature (signature supported)


� CVM List is 'signature' with a satisfied condition ie

* always or






� Transaction is processed so the outcome is an Approval



� The terminal shall print a ticket with signature line




2CJ.093.01 Second byte of CVR satisfied and CVM Code issignature (signature not supported)

Test No. 2CJ.093.01

Objective: To ensure that if the terminal does not support signature, the terminalperforms the CVM if the condition code is satisfied and CVM code issignature

Reference: 2RJ.063.61 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is signature (signature not supported)


� CVM List is 'signature' with a satisfied condition ie

* always or




� Terminal does not support signature








2CJ.094.00 Second byte of CVR satisfied and CVM Code is noCVM required (No CVM required is supported)

Test No. 2CJ.094.00

Objective: To ensure that if terminal supports No CVM required, the terminalconsiders that the CVM is successful if the condition code is satisfied andCVM code is 'No CVM required'

Reference: 2RJ.063.7 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is No CVM required (No CVM required issupported)


� CVM List is 'No CVM required' with a satisfied condition ie

* always or




� Terminal supports 'No CVM required'




� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification succeeded

� TSI byte 1, bit 7 = ‘1’ ie Cardholder verification was performed



2CJ.094.01 Second byte of CVR satisfied and CVM Code is NoCVM 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', theterminal considers that the CVM is successful if the condition code issatisfied and CVM code is 'No CVM required'

Reference: 2RJ.063.71 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code is No CVM required (No CVM required is notsupported)


� CVM List is 'No CVM required' with a satisfied condition i.e.

* always or




� Terminal does not support 'No CVM required'








2CJ.095.00 Second byte of CVR satisfied and CVM Code notunderstood by the terminal

Test No. 2CJ.095.00

Objective: To ensure that the terminal sets the ‘Unrecognized CVM ‘ bit in the TVR to1b, if the condition code is satisfied and CVM code is not understood by theterminal (RFU)

Reference: 2RJ.064.0 - Book 3 Section 6.5 - Second byte of Cardholder VerificationRule satisfied and CVM Code not understood by the terminal


� CVM List is 'RFU' with a satisfied condition ie

* always or







� TVR byte 3, bit 7 = ‘1’ ie Unrecognized CVM

� TSI byte 1, bit 7 = '1' ie Cardholder Verification was performed



2CJ.096.00 CVM processing succeeds

Test No. 2CJ.096.00

Objective: To ensure that the terminal does not set the ‘Cardholder verification wasnot 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



� CVM List such as at least one condition is met and CVM is performedOK (test can be made for several CVM: plaintext PIN verified by ICC,online PIN, signature...)



� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification successful




2CJ.097.00 CVM processing fails and CVR indicates toproceed with next rule

Test No. 2CJ.097.00

Objective: To ensure that the terminal processes next CVR in the CVM List, if thecurrent one is not successful and the ‘Apply succeeding CardholderVerification Rule if this CVM is unsuccessful’ bit is set to 1b

Reference: 2RJ.066.0 - Book 3 Section 6.5 - CVM processing fails and CardholderVerification Rules indicates to proceed with next rule



� CVM List such as it contains 2 CVRs and the first one has ‘Applysucceeding Cardholder Verification Rule, if this CVM is unsuccessful’ bitis set to 1b and is not successful whereas the second one is performedOK ( test can be made for several CVM: plaintext PIN verified by ICC,online PIN, signature...)



� TVR byte 3, bit 8 = ‘0’ ie Cardholder verification successful




2CJ.098.00 CVM processing fails and no more CVR in theCVM 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 CVMprocessing fails , and the ‘Apply succeeding Cardholder Verification Rule ifthis CVM is unsuccessful’ bit is set to 1b, and there are no more CardholderVerification Rules in the CVM List

Reference: 2RJ.067.0 - Book 3 Section 6.5 - CVM processing fails and no moreCardholder Verification Rules in the CVM List


� CVM List such as it contains only one CVR with condition OK but CVM isnot performed OK and this CVM has ‘Apply succeeding CardholderVerification Rule, if this CVM is unsuccessful’ bit is set to 1b







2CJ.099.00 CVM processing fails and CVR indicates to notproceed 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 CVMprocessing fails , and the ‘Apply succeeding Cardholder Verification Rule ifthis CVM is unsuccessful’ bit is not set to 1b.

Reference: 2RJ.068.0 - Book 3 Section 6.5 - CVM processing fails and CardholderVerification Rules indicates to not proceed with next rule


� CVM List such it contains one or several CVR and first CVR withcondition OK but CVM is not performed OK and this CVM has ‘Applysucceeding Cardholder Verification Rule if this CVM is unsuccessful’ bitis not set to 1b







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


� CVM List present (test is made for 2 cases CVM such as Cardholderverification is OK and CVM such as Cardholder verification fails)







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 asecond PIN entry if the VERIFY command returns 63 Cx and x is greaterthan 0

Reference: 2RJ.070.1 - Book 3 Section 6.5 - Offline PIN verification returns 63 Cx


� Terminal supports Offline PIN verification

� CVM List is 'PIN verified by ICC, always'

� LT returns ‘63C2’ to VERIFY command



� Terminal shall display a specific message and shall prompt for PIN entry



2CJ.103.00 Offline PIN is the selected CVM and Terminal doesnot support offline PIN

Test No. 2CJ.103.00

Objective: To ensure that the terminal sets the ‘PIN entry required and PIN pad notpresent or not working’ bit in the TVR to 1b, if an offline PIN is the selectedCVM and the terminal does not support either offline plaintext PINverification or offline enciphered PIN verification.

Reference: 2RJ.071.0 - Book 3 Section 6.5.1 - Offline PIN is the selected CVM andTerminal does not support offline PIN


� Terminal does not support Offline PIN verification









2CJ.104.00 Offline PIN is the selected CVM, Terminalsupports 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 notpresent or not working’ bit in the TVR to 1b, if an offline PIN is the selectedCVM 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


� Terminal PIN Pad is malfunctioning


� PIN pad to be non functional pad








2CJ.106.00 Offline PIN is the selected CVM and PIN isblocked

Test No. 2CJ.106.00

Objective: To ensure that the terminal sets the ‘PIN Try Limit exceeded’ bit in the TVRto 1b, if an offline PIN is the selected CVM and the PIN is blocked uponinitial 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 PINis blocked




� LT returns ‘6983’ or ‘6984’ to VERIFY command





� TVR byte 3, bit 6 = ‘1’ ie PIN Try Limit exceeded



2CJ.107.00 Offline PIN is the selected CVM and the number ofremaining PIN trials is zero

Test No. 2CJ.107.00

Objective: To ensure that the terminal sets the ‘PIN Try Limit exceeded’ bit in the TVRto 1b, if an offline PIN is the selected CVM and the number of remainingPIN 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 thenumber of remaining PIN trials is zero




� LT returns ‘63C0’ to VERIFY command








2CJ.108.00 Offline PIN is the selected CVM and the offline PINprocessing is successful

Test No. 2CJ.108.00

Objective: To ensure that the terminal consider the CVM as successful, if an offlinePIN 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 theoffline PIN processing is successful




� LT returns ‘90 00’ to VERIFY command








2CJ.109.00 Online PIN is the selected CVM and Terminal doesnot support online PIN

Test No. 2CJ.109.00

Objective: To ensure that the terminal sets the ‘PIN entry required and PIN pad notpresent or not working’ bit in the TVR to 1b, if enciphered PIN verifiedonline is the selected CVM and the terminal does not support encipheredPIN verified online.

Reference: 2RJ.077.0 - Book 3 Section 6.5.2 - Online PIN is the selected CVM andTerminal does not support online PIN


� Terminal does not support enciphered PIN verified online

� CVM List is 'Enciphered PIN verified online, always'








2CJ.110.00 Online PIN is the selected CVM, Terminalsupports 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 notpresent or not working’ bit in the TVR to 1b, if enciphered PIN verifiedonline 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


� Terminal PIN Pad is malfunctioning

� CVM List is 'Enciphered PIN verified online' always'








2CJ.112.00 Online PIN is the selected CVM and the online PINprocessing is successful

Test No. 2CJ.112.00

Objective: To ensure that the terminal consider the CVM as successful, if encipheredPIN verified online is the selected CVM and Issuer answered that PINpresented is good

Reference: 2RJ.080.0 - Book 3 Section 6.5.2 - Online PIN is the selected CVM and theonline PIN processing is successful


� Terminal supports enciphered PIN verified online

� CVM List is 'Enciphered PIN verified online, always'

� Issuer returns an acceptance








2CJ.113.00 Signature (paper) is a required CVM and Terminalsupports the signature process

Test No. 2CJ.113.00

Objective: To ensure that the terminal consider the CVM as successful, if signature isthe selected CVM and terminal supports the signature process

Reference: 2RJ.081.0 - Book 3 Section 6.5.3 - Signature (paper) is a required CVMand Terminal supports the signature process



� CVM List is 'signature, always'








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, ifall methods in the CVM are successful

Reference: 2RJ.082.0 - Book 3 Section 6.5.4 - Combination CVM: success



� Terminal supports plaintext PIN

� PIN entered is good

� CVM List is 'Plaintext PIN verified by ICC plus signature, always'








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 oneof the methods in the CVM fails

Reference: 2RJ.082.1 - Book 3 Section 6.5.4 - Combination CVM: failure


� Terminal supports plaintext PIN

� One test is made with PIN entered is not good and Terminal supportssignature, a second one with PIN entered is good and Terminal does notsupport signature

� CVM List is 'Plaintext PIN verified by ICC plus signature, always'








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, theterminal performs Risk Management at any time after Read ApplicationData and prior to the issuing of the first GENERATE AC command

Reference: 2RJ.083.0 - Book 3 Section 6.6 - Terminal Risk Management is supportedin 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 AuthorizedNumeric



� 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



� TVR byte 1, bit 6 = ‘1’ ie ICC Data missing



2CJ.118.00 Terminal Risk Management is not supported inAIP

Test No. 2CJ.118.00

Objective: To ensure that if the card does not support Terminal Risk Management, theterminal does not perform Floor Limit checking, Random transactionselection and velocity checking

Reference: 2RJ.085.0 - Book 3 Section 6.6 - Terminal Risk Management is notsupported in AIP

Conditions: � LT does not support Terminal Risk Management




� CDOL1 requests TSI and TVR and Terminal Floor Limit and AmountAuthorized Numeric



� 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 notexceeded

� TVR byte 4, bit 6 = ‘0’ ie Upper Consecutive Offline Limit is notexceeded

� TSI byte 1, bit 4 = ‘0’ ie Terminal Risk Management was not performed



2CJ.119.00 Transaction log entry with the same PAN isavailable and Terminal Floor Limit is exceeded

Test No. 2CJ.119.00

Objective: To ensure that the terminal sets the ‘Transaction exceeds floor limit’ bit inthe TVR to 1b, if a transaction log entries with the same Application PAN, isavailable and if the sum of the Amount, Authorized to the Amount stored inthe most recent log entry for that PAN is greater than or equal to theTerminal Floor Limit

Reference: 2RJ.086.0 - Book 3 Section 6.6.1 - Transaction log entry with the samePAN is available and Terminal Floor Limit is exceeded


� Transaction log is available if supported by the terminal with the samePAN as the LT PAN (another transaction has been made with samePAN before with Amount less than Terminal floor Limit)

� sum of Transaction Amount, Authorized and Amount stored in the log isequal to or greater than Terminal floor Limit (Amount Authorized caninclude a cash back amount)

� CDOL1 requests TVR and TSI and Terminal Floor Limit and AmountAuthorized




� Amount Authorized returned in First GENERATE AC is the same as theamount entered and sum of Transaction Amount, Authorized andAmount of previous transaction with same PAN is equal to or greaterthan Terminal floor Limit




2CJ.120.00 Transaction log entry with the same PAN isavailable 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 floorlimit’ bit in the TVR to 1b, if a transaction log entries with the sameApplication PAN, is available and if the sum of the Amount, Authorized tothe Amount stored in the most recent log entry for that PAN is less than theTerminal Floor Limit

Reference: 2RJ.086.1 - Book 3 Section 6.6.1 - Transaction log entry with the samePAN is available and Terminal Floor Limit is not exceeded (implied)


� Transaction log is available if supported by the terminal with the samePAN as the LT PAN (another transaction has been made with samePAN before with Amount less than Terminal floor Limit)

� Sum of Transaction Amount, Authorized and Amount stored in the log isless than Terminal floor Limit (Amount Authorized can include a cashback amount)





� Amount Authorized returned in First GENERATE AC is the same as theamount entered and sum of Transaction Amount, Authorized andAmount of previous transaction with same PAN is less than Terminalfloor Limit




2CJ.123.00 Transaction log is not available and TerminalFloor Limit is exceeded

Test No. 2CJ.123.00

Objective: To ensure that the terminal sets the ‘Transaction exceeds floor limit’ bit inthe 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 andTerminal Floor Limit is exceeded


� Transaction log is not available

� Transaction Amount, Authorized is equal to or greater than Terminalfloor Limit (Amount Authorized can include a cash back amount)





� Amount Authorized returned in First GENERATE AC is the same as theamount entered and Transaction Amount, Authorized is equal to orgreater than Terminal floor Limit




2CJ.124.00 Transaction log is not available and TerminalFloor Limit is not exceeded (implied)

Test No. 2CJ.124.00

Objective: To ensure that the terminal does not set the ‘Transaction exceeds floorlimit’ bit in the TVR to 1b, if no transaction log is available and if theAmount, Authorized is less than the Terminal Floor Limit

Reference: 2RJ.087.1 - Book 3 Section 6.6.1 - Transaction log is not available andTerminal Floor Limit is not exceeded (implied)


� Transaction log is not available

� Transaction Amount, Authorized is less than Terminal floor Limit(Amount Authorized can include a cash back amount)






� Amount Authorized returned in First GENERATE AC is the same as theamount entered and Transaction Amount, Authorized is less thanTerminal floor Limit




2CJ.127.00 Transaction log entry with the same PAN is notavailable and Terminal Floor Limit is exceeded

Test No. 2CJ.127.00

Objective: To ensure that the terminal sets the ‘Transaction exceeds floor limit’ bit inthe TVR to 1b, if no transaction log with the same PAN is available and ifthe 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 samePAN is not available and Terminal Floor Limit is exceeded


� Transaction log is not available for same PAN (another transaction asbeen made with another PAN before with Amount less than Terminalfloor Limit)

� Transaction Amount, Authorized is equal to or greater than Terminalfloor Limit (Amount Authorized can include a cash back amount)





� Amount Authorized returned in First GENERATE AC is the same as theamount entered and Transaction Amount, Authorized is equal to orgreater than Terminal floor Limit




2CJ.128.00 Transaction log entry with the same PAN is notavailable 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 floorlimit’ bit in the TVR to 1b, if no transaction log with the same PAN isavailable 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 samePAN is not available and Terminal Floor Limit is not exceeded (implied)


� Transaction log is not available for same PAN (another transaction hasbeen made with another PAN before with Amount less than Terminalfloor Limit)

� Transaction Amount, Authorized is less than Terminal floor Limit(Amount Authorized can include a cash back amount)






� Amount Authorized returned in First GENERATE AC is the same as theamount entered and Transaction Amount, Authorized is less thanTerminal floor Limit




2CJ.137.00 Both the Lower and the Upper Consecutive OfflineLimit are present in the ICC

Test No. 2CJ.137.00

Objective: To ensure that if Lower and Upper Consecutive Offline Limits are present inthe card, the terminal performs the velocity checking

Reference: 2RJ.095.0 - Book 3 Section 6.6.3 - Both the Lower and the UpperConsecutive Offline Limit are present in the ICC




� CDOL 1 requests TVR









2CJ.138.00 Either the Lower or the Upper Consecutive OfflineLimit is not present in the ICC

Test No. 2CJ.138.00

Objective: To ensure that if either Lower or Upper Consecutive Offline Limits is absentin 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 UpperConsecutive Offline Limit is not present in the ICC


� either Lower or Upper Consecutive Offline Limits is absent in the LT




� 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 theLOATC



2CJ.139.00 GET DATA on both the ATC and the Last OnlineATC Register

Test No. 2CJ.139.00

Objective: To ensure that if terminal performs the velocity checking, it reads the ATCand Last online ATC using GET DATA command

Reference: 2RJ.097.0 - Book 3 Section 6.6.3 - GET DATA on both the ATC and theLast Online ATC Register





� LT shall receive 2 GET DATAs command for ATC and Last Online ATC



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 theGET DATA command, the terminal sets both the ’Lower consecutive offlinelimit exceeded’ and the ‘Upper consecutive offline limit exceeded’ bits in theTVR 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 ATCRegister is not present in the ICC

Conditions: � LT supports Terminal Risk Management (AIP)

� Terminal shall support Risk management



� If returned, Last Online ATC is 0

� CDOL1 Requests TVR





� TVR byte 2, bit 4 = ‘0’ ie not a new card




2CJ.140.01 The Last Online ATC Register is not present in theICC

Test No. 2CJ.140.01

Objective: To ensure that if the Last Online ATC is not returned by the card inresponse to the GET DATA command, the terminal sets both the ’Lowerconsecutive offline limit exceeded’ and the ‘Upper consecutive offline limitexceeded’ bits in the TVR to 1b and does not set the ‘New Card’ bit in theTVR to 1b

Reference: 2RJ.098.0 - Book 3 Section 6.6.3 - Either the ATC or the Last Online ATCRegister is not present in the ICC

Conditions: � LT supports Terminal Risk Management (AIP)



� Last Online ATC is not returned by GET DATA

� If returned, Last Online ATC is 0










2CJ.141.00 (ATC - Last Online ATC Register) > LowerConsecutive Offline Limit

Test No. 2CJ.141.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is greater than the Lower Consecutive Offline Limit, the terminalsets 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



� ATC and Last Online ATC are returned by GET DATA

� ATC - Last Online ATC > Lower Consecutive Offline Limit







2CJ.142.00 (ATC - Last Online ATC Register) = LowerConsecutive Offline Limit (implied)

Test No. 2CJ.142.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is equal to the Lower Consecutive Offline Limit, the terminal doesnot 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)




� ATC - Last Online ATC = Lower Consecutive Offline Limit








2CJ.143.00 (ATC - Last Online ATC Register) < LowerConsecutive Offline Limit (implied)

Test No. 2CJ.143.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is less than the Lower Consecutive Offline Limit, the terminal doesnot 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)




� ATC - Last Online ATC < Lower Consecutive Offline Limit








2CJ.144.00 (ATC - Last Online ATC Register) > UpperConsecutive Offline Limit

Test No. 2CJ.144.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is greater than the Upper Consecutive Offline Limit, the terminalsets 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




� ATC - Last Online ATC > Upper Consecutive Offline Limit







2CJ.145.00 (ATC - Last Online ATC Register) = UpperConsecutive Offline Limit (implied)

Test No. 2CJ.145.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is equal to the Upper Consecutive Offline Limit, the terminal doesnot 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)




� ATC - Last Online ATC = Upper Consecutive Offline Limit








2CJ.146.00 (ATC - Last Online ATC Register) < UpperConsecutive Offline Limit (implied)

Test No. 2CJ.146.00

Objective: To ensure that if the difference between the ATC and the Last Online ATCRegister is less than the Upper Consecutive Offline Limit, the terminal doesnot 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)




� ATC - Last Online ATC < Upper Consecutive Offline Limit








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




� Last Online ATC when returned by GET DATA have the value = 0







2CJ.148.00 Terminal Risk Management completion

Test No. 2CJ.148.00

Objective: To ensure that the terminal sets the ‘Terminal Risk Management wasperformed’ bit in the TSI to 1b, when the Terminal Risk management iscompleted

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









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 ofthe first GENERATE AC command

Reference: 2RJ.103.0 - Book 3 Section 6.7 - Terminal Action Analysis functionexecution

Conditions: � IAC and data in the LT are populated so that Terminal decision followingAction Analysis is TC, ARQC and AAC (3 cases)



� The LT shall receive a first GENERATE AC command requesting acryptogram in accordance with IAC and Data Above



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, iffor a bit set to 1b in the TVR, the corresponding bit in the TAC Denial is setto 1b

Reference: 2RJ.115.1 – Book 3 Section 6.7 - TVR and Terminal Action Code Denialcheck requests an AAC.

Conditions: � Terminal Action Code Denial has one bit set to 1b and thecorresponding 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 bitselected by tester and the LT will be set so the executed function will fail



� The LT shall receive a first GENERATE AC command requesting anAAC in all cases



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 fora bit set to 1b in the TVR, the corresponding bit in the TAC Denial is set to0b

Reference: 2RJ.112.0 - Book 3 Section 6.7 - Denial Action Codes processing. Theterminal shall process first the denial Action Codes during the terminalaction analysis.

Conditions: � Terminal Action Code Denial has one bit set to 0b and thecorresponding 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 bitselected by the tester, and the LT will be set so the executed functionwill fail



� The LT shall receive a first GENERATE AC command requesting an TCin all cases.



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 andTerminal 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 thecorresponding TVR bit is set to 1b

� Terminal Action Code Denial has all bits set to 0b




� The LT shall receive a first GENERATE AC command requesting anARQC in all cases



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, ifthe terminal has online capabilities and if for a bit set to 1b in the TVR, thecorresponding bit in the TAC Online is set to 0b

Reference: 2RJ.116.2 - Book 3 Section 6.7 - Terminal has online capability, TVR andOnline Action Codes check does not request an ARQC

Conditions: � Terminal Action Code Online has one bit set to 0b and thecorresponding TVR bit is set to 1b



� Terminal has online capabilities




� The LT shall receive a first GENERATE AC command requesting a TCin all cases



2CJ.154.00 TAC Default processing bit set to 1b, & terminalunable to go online

Test No. 2CJ.154.00

Objective: To ensure that the terminal issues a second GENERATE AC requesting anAAC, if online connection was requested after first GENERATE AC andterminal is unable to go online and for a bit set to 1b in the TVR, thecorresponding 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 andTerminal 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


� Terminal Action Code Default has one bit set to 1b and thecorresponding TVR bit is set to 1b




� The LT shall receive a second GENERATE AC command requesting anAAC in all cases



2CJ.155.00 TAC Default processing bit set to 0b, & terminalunable to go online

Test No. 2CJ.155.00

Objective: To ensure that the terminal issues a second GENERATE AC requesting aTC, if online connection was requested after first GENERATE AC andterminal is unable to go online and for each bit set to 1b in the TVR, thecorresponding 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 andDefault Action Codes check requests a TC

Conditions: � Terminal Action Codes Denial have all bit set to 0b


� Terminal has online capabilities and unable to go online






� The LT shall receive a second GENERATE AC command requesting aTC in all cases



2CJ.156.00 TAC Default processing bit set to 1b, & terminalhas no online capability

Test No. 2CJ.156.00

Objective: To ensure that the terminal skips the check of Online Action Codes andissues a first GENERATE AC requesting an AAC, if terminal has no onlinecapabilities and for a bit set to 1b in the TVR, the corresponding bit in theTAC Default is set to 1b

Reference: 2RJ.120.1 - Book 3 Section 6.7 - Terminal has not online capability, TVRand 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









2CJ.157.00 TAC Default processing bit set to 0b, & terminalhas no online capability

Test No. 2CJ.157.00

Objective: To ensure that the terminal skips the check of Online Action Codes andissues a first GENERATE AC requesting a TC, if terminal has no onlinecapability and for each bit set to 1b in the TVR, the corresponding bit inboth the IAC Default and TAC-Default is set to 0b

Reference: 2RJ.121.0 - Book 3 Section 6.7 - Terminal has not online capability, TVRand 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


� Issuer Action Code Default has all bits set to 0b








Issuer Action Code (IAC)

2CJ.158.00 TVR and Issuer Action Code-Denial checkrequests an AAC

Test No. 2CJ.158.00

Objective: To ensure that the terminal issues a GENERATE AC requesting an AAC iffor a bit is set to 1b in the TVR the corresponding bit in the IAC Denial is setto 1b.

Reference: 2RJ.111.0 - Book 3 Section 6.7 - TVR and Issuer Action Code-Denial checkrequests an AAC

Conditions: � Issuer Action Code Denial has one bit set to 1b and the correspondingTVR 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 bitselected by tester and the LT will be set so the executed function will fail






2CJ.159.00 TVR and IAC-Denial check requests a TC(implied)

Test No. 2CJ.159.00

Objective: To ensure that the terminal issues a GENERATE AC requesting a TC if fora bit is set to 1b in the TVR, the corresponding bit in the IAC Denial is set to0b.

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 correspondingTVR 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 bitselected by the tester, and the LT will be set so the executed functionwill fail



� The LT shall receive a first GENERATE AC command requesting an TCin all cases



2CJ.160.00 Terminal has online capability, TVR and IssuerAction 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 andIssuer Action Code-Online check requests an ARQC


� Issuer Action Codes Denial & Default have all bits set to 0b

� Issuer Action Code Online has one bit set to 1b and the correspondingTVR bit is set to 1b

� Terminal Action Code has all bits set to 0b




� The LT shall receive a first GENERATE AC command requesting anARQC in all cases



2CJ.161.00 Terminal has online capability, TVR and OnlineAction Codes check requests a TC (implied)

Test No. 2CJ.161.00

Objective: To ensure that the terminal Issues a GENERATE AC requesting a TC, ifterminal has online capabilities, and if for a bit set to 1b in the TVR, thecorresponding bit in the IAC Online is set to 0b

Reference: 2RJ.116.2 - Book 3 Section 6.7 - Terminal has online capability, TVR andOnline Action Codes check requests a TC (implied)


� 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 correspondingTVR bit is set to 1b







2CJ.162.00 Terminal is unable to go online, TVR and IssuerAction Code-Default check requests an AAC

Test No. 2CJ.162.00

Objective: To ensure that the terminal issues a second GENERATE AC requesting anAAC, if online connection was requested after first GENERATE AC andterminal is unable to go online and for a bit set to 1b in the TVR, thecorresponding 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 andIssuer Action Code-Default check requests an AAC

Conditions: � Issuer Action Codes Denial have all bits set to 0b


� Terminal has online capabilities, and was unable to go online

� Issuer Action Code Default has one bit set to 1b and the correspondingTVR bit is set to 1b





� In all cases, the LT shall receive a second GENERATE AC commandrequesting an AAC



2CJ.163.00 Terminal is unable to go online, TVR and DefaultAction Codes check requests a TC

Test No. 2CJ.163.00

Objective: To ensure that the terminal issues a second GENERATE AC requesting anTC, if online connection was requested after first GENERATE AC andterminal is unable to go online and for a bit set to 1b in the TVR, thecorresponding 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 andDefault Action Codes check requests a TC



� Terminal has online capabilities, and was unable to go online






� The LT shall receive a second GENERATE AC command requesting aTC in all cases



2CJ.164.00 Terminal has not online capability, TVR and IssuerAction Code-Default check requests an AAC

Test No. 2CJ.164.00

Objective: To ensure that the terminal skips the check of Online Action Codes andissues a first GENERATE AC requesting an AAC, if terminal has notrejected the transaction and terminal has no online capabilities and for a bitset 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, TVRand Issuer Action Code-Default check requests an AAC












2CJ.165.00 Terminal has not online capability, TVR andDefault Action Codes check requests a TC

Test No. 2CJ.165.00

Objective: To ensure that the terminal skips the check of Online Action Codes andissues a first GENERATE AC requesting a TC, if terminal has not rejectedthe transaction and terminal has no online capabilities and for a bit set to 1bin 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, TVRand Default Action Codes check requests a TC





� Terminal Action Codes has all bit set to 0b




� The LT shall receive a first GENERATE AC command requesting an TCin all cases



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 presentin the ICC

Conditions: � Issuer Action Code Denial does not exist in the card


� 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 bitselected by the tester and the LT will be set so the executed function willfail



� The LT shall receive a first GENERATE AC command requesting acryptogram different from AAC for all tests



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 presentin 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




� The LT shall receive a first GENERATE AC command requesting anARQC



2CJ.168.00 IAC-Default is not present in the ICC and theTerminal 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 isunable to go online.

Reference: 2RJ.109.0 - Book 3 Section 6.7 - Issuer Action Code-Default is not presentin 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


� LT requests ARQC to first GENERATE AC command

� Terminal unable to go online (no response received from issuer forinstance)






2CJ.169.00 IAC-Default is not present in the ICC and theTerminal 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 isoffline only.

Reference: 2RJ.109.5 - Book 3 Section 6.7 & Book 3 Section 5.3 - Issuer Action Code-Default is not present in the ICC and the Terminal is offline only

Conditions: � Terminal checks Default IAC prior to First Generate AC



� 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 thisfunction will be failed by the LT" (e.g. SDA is failed then the TVR byte 1bit 7 is set to 1b).

� Terminal is offline only






2CJ.169.02 IAC-Default is not present in the ICC and theTerminal 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 isoffline only

Reference: 2RJ.109.7 - Book 3 Section 6.7 - Issuer Action Code-Default is not presentin the ICC and the Terminal is offline only

Conditions: � Terminal checks Default IAC after First Generate AC



� 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 thisfunction will be failed by the LT"(e.g. SDA is failed then the TVR byte 1bit 7 is set to 1).

� LT requests ARQC in First Generate AC

� The terminal is offline only






2CJ.169.05 Tag for Terminal Capability Profile not include inICC's CDOL1

Test No. 2CJ.169.05

Objective: To ensure that if Combined DDA / AC Generation is to be performed andthe ICC's CDOL 1 does not include the tag for the Terminal CapabilityProfile, the terminal shall set the bit for Combined DDA / AC GenerationRequest in the GENERATE AC command to '1'.

Reference: 2RJ.122.0 - Book 3 Section 6.7 - Combined DDA/AC Generation MissingTag

Conditions: � Terminal and LT support Combined DDA / AC Generation

� CDOL 1 does not include Terminal Capability Profile Tag



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 wasperformed’ bit in the TSI to 1b after an ARQC is returned by the card. (Testis 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




� TSI byte 1, bit 6 = ‘1’ ie the Card Risk Management was performed



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 CombinedDDA/AC and the ICC response is an offline approval (TC) or an onlinerequest (ARQC), and if the ICC returns the Generate AC response in apublic key envelope as specified in Book 2 Section 6.6, the terminal is ableto interpret correctly this response.



� LT answers with a TC or an ARQC to the first Generate AC

� LT returns its Generate AC response in a public key envelope



� 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 theissuer, if the ‘Advice required’ bit is set to 1b in the Cryptogram InformationData.

Reference: 2RJ.125.0 - Book 3 Section 6.8.3 - Advice messages during Card ActionAnalysis

Conditions: � LT answers to the Generate AC with the bit 4 of its CryptogramInformation Data (CID) sets to '1'.




� The terminal shall format and send an advice.



2CJ.178.00 Online Processing function execution

Test No. 2CJ.178.00

Objective: To ensure that the terminal performs the Online Processing function if thecard 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 firstGENERATE AC command



� The Terminal shall prepare and send Authorization or Financial requestmessage for the issuer



2CJ.180.00 IAD is received from the Issuer and IssuerAuthentication is supported in AIP

Test No. 2CJ.180.00

Objective: To ensure that the terminal issue EXTERNAL AUTHENTICATE commandwith IAD received if the card supports Issuer Authentication in AIP and ifIAD is present in authorization response message

Reference: 2RJ.128.0 - Book 3 Section 6.9 - IAD is received from the Issuer and IssuerAuthentication is supported in AIP


� The LT supports Issuer Authentication (AIP byte 1 bit 3 = ‘1’)

� Authorization response message contains IAD


Pass Criteria: � The LT shall receive an EXTERNAL AUTHENTICATE command afterthe first GENERATE AC

� Data field of EXTERNAL AUTHENTICATE received by LT shall containIAD as received from Issuer



2CJ.181.00 EXTERNAL AUTHENTICATE unsuccessful

Test No. 2CJ.181.00

Objective: To ensure that the terminal sets the ‘Issuer authentication wasunsuccessful’ bit’ in the TVR to 1b, if status received from the card inresponse to EXTERNAL AUTHENTICATE is different from ‘90 00’.

Reference: 2RJ.129.0 - Book 3 Section 6.9 - EXTERNAL AUTHENTICATEunsuccessful




� LT returns status different from ‘90 00’ in response to EXTERNALAUTHENTICATE




� TVR byte 5, bit 7 = ‘1’ ie Issuer Authentication was unsuccessful



2CJ.182.00 IAD is received from the Issuer and IssuerAuthentication is not supported in AIP

Test No. 2CJ.182.00

Objective: To ensure that the terminal does not send EXTERNAL AUTHENTICATEcommand if the card does not support Issuer Authentication in AIP and ifIAD is present in authorization response message

Reference: 2RJ.130.0 - Book 3 Section 6.9 - IAD is received from the Issuer and IssuerAuthentication is not supported in AIP


� The LT does not support Issuer Authentication (AIP byte 1 bit 3 = ‘0’)




� LT shall not receive EXTERNAL AUTHENTICATE command after firstGENERATE AC



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 AUTHENTICATEcommand, if the card supports Issuer Authentication in AIP and if IAD is notpresent in authorization response message

Reference: 2RJ.131.0 - Book 3 Section 6.9 - IAD is not received from the Issuer



� Authorization response message does not contain IAD



� LT shall not receive EXTERNAL AUTHENTICATE command after firstGENERATE AC



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 sentto the card

Reference: 2RJ.133.0 - Book 3 Section 6.9 - EXTERNAL AUTHENTICATE performed







� TSI byte 1, bit 5 = ‘1’ ie the Issuer Authentication was performed



2CJ.186.00 Multiple Issuer Scripts may be provided with asingle authorization response

Test No. 2CJ.186.00

Objective: To ensure that the terminal is able to receive and manage multiple Issuerscripts in a single authorization message

Reference: 2RJ.134.0 - Book 3 Section 6.10 - Multiple Issuer Scripts may be providedwith a single authorisation response


� Authorization response message contains several Issuer scripts

� LT returns ‘90 00’ to each command of the scripts



� The LT shall receive commands according to the several scriptscontained in the authorization response



2CJ.187.00 Issuer Script may contain several Issuer ScriptCommands

Test No. 2CJ.187.00

Objective: To ensure that the terminal is able to receive and manage Issuer scriptscontaining several commands

Reference: 2RJ.135.0 - Book 3 Section 6.10 - Issuer Script may contain several IssuerScript Commands


� Authorization response message contains one Issuer script with severalcommands

� LT returns ‘90 00’ to each command of the script



� The LT shall receive a sequence of commands according to the scriptcontained in the authorization response



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 commandcontained in a script to the card

Reference: 2RJ.136.0 - Book 3 Section 6.10 - Issuer Script Command unknown to theterminal


� Authorization response message contains one Issuer script with severalnon EMV commands




� The LT shall receive a sequence of non EMV commands according tothe script contained in the authorization response



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 thesecond GENERATE AC

Reference: 2RJ.137.0 - Book 3 Section 6.10 - Issuer Script with Tag ‘71’ execution


� Authorization response message contains one Issuer script with Tag 71




� The LT shall receive a sequence of commands according to the scriptcontained 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 thesecond GENERATE AC

Reference: 2RJ.138.0 - Book 3 Section 6.10 - Issuer Script with Tag ‘72’ execution






� The LT shall receive a sequence of commands according to the scriptcontained in the authorization response after the final GENERATE AC



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 aconstructed data object containing a Script Identifier and a sequence ofIssuer Script Command APDUs

Reference: 2RJ.139.0 - Book 3 Section 6.10 - Issuer Script Format


� Authorization response message contains one Issuer script with a scriptIdentifier




� The LT shall receive a sequence of commands APDUs according to thescript contained in the authorization response



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 withoutoptional Script Identifier.

Reference: 2RJ.140.0 - Book 3 Section 6.10 - Script Identifier in Issuer Script


� Authorization response message contains one Issuer script withoutscript Identifier




� The LT shall receive a sequence of commands APDUs according to thescript 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 appearsin authorization response

Reference: 2RJ.141.0 - Book 3 Section 6.10 - Issuer Script processing


� Authorization response message contains several Issuer script

� LT returns ‘90 00’ to each command of a script



� The LT shall receive a sequence of commands APDUs in the order inwhich scripts were in the authorization response



2CJ.194.00 Issuer Script Commands not BER-TLV encodedand Issuer Script tag is ‘71’

Test No. 2CJ.194.00

Objective: To ensure that the terminal sets the ‘Script processing failed before finalGENERATE AC’ bit in the TVR to 1b, if the command contained in thescript 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-TLVencoded and Issuer Script tag is ‘71’


� Authorization response message contains an Issuer script with Tag 71

� command in Issuer Script are not BER-TLV encoded in tag ‘86’




� TVR byte 5, bit 6 = ‘1’ ie Script processing failed before finalGENERATE AC



2CJ.195.00 Issuer Script Commands not BER-TLV encodedand Issuer Script tag is ‘72’

Test No. 2CJ.195.00

Objective: To ensure that the terminal sets the ‘Script processing failed after finalGENERATE AC’ bit in the TVR to 1b, if the command contained in thescript 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-TLVencoded and Issuer Script tag is ‘72’


� Authorization response message contains an Issuer script with Tag 72

� command in Issuer Script are not BER-TLV encoded in tag ‘86’




� TVR byte 5, bit 5 = ‘1’ ie Script processing failed after final GENERATEAC



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 thesequence they appear in the script

Reference: 2RJ.144.0 - Book 3 Section 6.10 - Issuer Script Commands delivery to ICC


� Authorization response message contains a script with severalcommands

� LT returns ‘90 00’ to each command of a script



� The LT shall receive a sequence of commands APDUs in the order inwhich they were in the script received in the authorization response



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 ifthe 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’



� LT returns 90 00 to script command 1

� LT returns 62 xx to script command 2


� LT returns 90 00 to other script commands



� The LT shall receive all the commands contained in the script



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 beforefinal 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’ or62’, or ‘63’ (implied)



� LT returns 90 00 to script command 1



� LT returns 90 00 to other script commands





� TVR byte 5 bit 6 = ‘0’ ie Script processing did not fail before finalGENERATE AC (if transactions are batch captured, TVR after finalGENERATE AC is in Batch Data Capture Message)



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 finalGENERATE AC’ bit in the TVR to 1b, if Script Tag is 71 and SW1 in thestatus 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’



� LT returns SW1 different from ‘90’ or ‘62’, or ‘63’ to one of the scriptcommands




� TVR byte 5 bit 6 = ‘1’ ie Script processing failed before final GENERATEAC



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 finalGENERATE AC’ bit in the TVR to 1b, if Script Tag is 72 and SW1 in thestatus 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’



� LT returns SW1 different from ‘90’ or ‘62’, or ‘63’ to one of the scriptcommands




� TVR byte 5, bit 5 = ‘1’ ie Script processing failed after final GENERATEAC



2CJ.201.00 Issuer Script processed

Test No. 2CJ.201.00

Objective: To ensure that the terminal sets the ‘Script processing was performed’ bit inthe TSI to 1b, if one script was received in the authorization response andwas processed by the terminal

Reference: 2RJ.148.0 - Book 3 Section 6.10 - Issuer Script processed






� TSI byte 1 bit 3 = ‘1’ ie Script processing was performed



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 wasperformed’ bit in the TSI to 1b, if no script was received in the authorizationresponse

Reference: 2RJ.148.1 - Book 3 Section 6.10 - Issuer Script not processed (implied)


� Authorization response message does not contains any Issuer script





� TSI byte 1 bit 3 = ‘0’ ie Script processing was not performed



2CJ.203.00 Enhanced Combined DDA/AC failed when ICCresponded with TC (1)

Test No. 2CJ.203.00

Objective: To ensure that the terminal declines the transaction if ICC has respondedwith TC and Enhanced Combined DDA/AC failed (1st Generate AC)


Conditions: � CDOL1 in LT does not include Unpredictable Number generated by theterminal (tag 9F 37)


� LT responds TC to the 1st Generate AC


Pass Criteria: � The terminal shall decline the transaction after the 1st Generate AC.





2CJ.203.01 Enhanced Combined DDA/AC failed when ICCresponded with TC (2)

Test No. 2CJ.203.01

Objective: To ensure that the terminal declines the transaction if ICC has respondedwith TC and Enhanced Combined DDA/AC failed (2nd Generate AC)


Conditions: � CDOL1 in LT includes Unpredictable Number generated by the terminal(tag 9F 37)


� CDOL2 does not include Unpredictable Number

� LT responds TC to the 2nd Generate AC

� LT responds ARQC to the 1st Generate 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 storedeclined transactions.




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 fieldaccording 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


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT withData 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 fieldaccording 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


Pass Criteria: � The terminal shall return a second GENERATE AC command to the LTwith Data field correctly filled according to CDOL2



2CK.003.00 CDOL requests a TC Hash Value and TDOL ispresent in the ICC

Test No. 2CK.003.00

Objective: To ensure that if TC Hash Value is requested in CDOL, the terminal is ableto 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 andTDOL is present in the ICC

Conditions: � LT contains TDOL

� CDOL1 requests TC Hash value


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT withData field containing a TC Hash value correctly calculated



2CK.004.00 CDOL requests a TC Hash Value and TDOL is notpresent in the ICC

Test No. 2CK.004.00

Objective: To ensure that if TC Hash Value is requested in CDOL, and TDOL is notprovided by the card, the terminal is able to calculate TC Hash valueaccording 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 andTDOL 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)


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT withData field containing a TC Hash value correctly calculated with defaultTDOL as input

� TVR byte 5, bit 8 = ‘1’ ie Default TDOL used



2CK.005.00 CDOL requests a TC Hash Value and neitherTDOL 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 notprovided by the card and there is no default TDOL in terminal, the terminalis 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 andneither 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


Pass Criteria: � The terminal shall return a GENERATE AC command to the LT withData field containing a TC Hash value correctly calculated with a TDOLwith no entry

� TVR byte 5, bit 8 = ‘0’ ie Default TDOL not used



2CK.006.00 CDOL requests a TC Hash Value during thesecond GENERATE AC

Test No. 2CK.006.00

Objective: To ensure that if TC Hash Value is requested in CDOL2, the terminalensure that the data provided in the TC Hash value is current at the timethe command is issued

Reference: 2RK.006.0 - Book 3 Section 5.2.2 - CDOL requests a TC Hash Valueduring the second GENERATE AC

Conditions: � LT contains TDOL

� TDOL requests TSI


� CDOL2 requests TSI and TC Hash value

� LT returns ARQC to first GENERATE AC

� Issuer Authentication is supported and performed


Pass Criteria: � The terminal shall return a second GENERATE AC command to the LTwith Data field containing a TC Hash value correctly calculated (inparticular with TSI with ‘Issuer Authentication was performed ‘ bit set)

� TSI returned in first GENERATE AC byte 1, bit 5 = ‘0’ ie IssuerAuthentication was not performed

� TSI returned in second GENERATE AC byte 1, bit 5 = ‘1’ ie IssuerAuthentication was performed



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, itsupports 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 firstGENERATE 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 firstGENERATE AC (4 tests)


Pass Criteria: � The terminal shall process the transaction until completion according tothe type of cryptogram received.

2CK.008.00 Terminal requests an ARQC on first GENERATEAC

Test No. 2CK.008.00

Objective: To ensure that if the terminal requests an ARQC in first GENERATE AC, itsupports 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 firstGENERATE AC

Conditions: � IAC and TAC set so that Terminal requests ARQC on first GENERATEAC

� LT returns AAC, or ARQC or AAR in the response to first GENERATEAC (3 tests)





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, itsupports AAC in the response from the card

Reference: 2RK.009.0 - Book 3 Section 5.3.1 - Terminal requests an AAC on firstGENERATE 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



2CK.010.00 Card responds with an ARQC on first GENERATEAC

Test No. 2CK.010.00

Objective: To ensure that if the card responds with an ARQC to first GENERATE ACand is permitted to do so and if terminal has online capability, the terminalprepares and sends an authorization or financial request message

Reference: 2RK.010.0 - Book 3 Section 5.3.1 - Card responds with an ARQC on firstGENERATE AC

Conditions: � All Action Code Denial bits are set to 0b to prevent the terminal fromrequesting an AAC on the first GENERATE AC

� LT returns ARQC in the response to first GENERATE AC

� Terminal has online capability


Pass Criteria: � The terminal shall prepare and send an authorization or financial requestmessage.



2CK.011.00 Card responds with an AAR on first GENERATEAC

Test No. 2CK.011.00

Objective: To ensure that if the card responds with an AAR to first GENERATE ACand is permitted to do so, the terminal either provides an AuthorizationResponse Code and proceeds to the completion function or use the AAR togo online

Reference: 2RK.011.0 - Book 3 Section 5.3.1 - Card responds with an AAR on firstGENERATE AC

Conditions: � LT returns AAR in the response to first GENERATE AC

� CDOL2 requests Authorization Response Code


Pass Criteria: � If Terminal uses AAR to go online, The terminal shall either prepare andsend an authorization or financial request message with AAR instead ofARQC

� If Terminal proceeds offline, the LT shall receive a second GENERATEAC with cryptogram requested in accordance with AuthorizationResponse Code provided by the terminal



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 ispermitted 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 firstGENERATE AC

Conditions: � All Action Codes have all bits set to 0b

� LT returns TC in the response to first GENERATE AC


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 firstGENERATE AC

Conditions: � LT returns AAC in the response to first GENERATE AC


Pass Criteria: � The terminal shall complete the transaction offline (declined).



2CK.015.00 Terminal requests an AAC on second GENERATEAC

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 othercryptogram as an AAC

Reference: 2RK.013.0 - Book 3 Section 5.3.2 - Terminal requests an AAC on secondGENERATE 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 secondGENERATE AC (4 tests)

� Host Source shall return denial response in the authorization response


Pass Criteria: � The terminal shall process the transaction until completion according tothe 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 respondswith a cryptogram with higher level than one requested in first GENERATEAC

Reference: 2RK.015.0 - Book 3 Section 5.3 - Cryptogram at a higher level thanrequested (1)

Conditions: � LT returns TC to first GENERATE AC requesting AAC or ARQC

� LT returns TC or ARQC to first GENERATE AC requesting AAC


Pass Criteria: � In all cases, the terminal shall terminate the transaction



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 thecryptogram as an AAC if the card responds with a cryptogram with higherlevel than one requested in second GENERATE AC

Reference: 2RK.016.0 - Book 3 Section 5.3 - Cryptogram at a higher level thanrequested (2)

2RK.012.0 - Book 3 Section 5.3.2 - Terminal requests a TC on secondGENERATE AC

Conditions: LT returns TC or ARQC to second GENERATE AC requesting AAC


Pass Criteria: In all cases, the terminal shall complete the transaction and consider thecryptogram 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 ismissing 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





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 DFName is missing in a response to SELECT PSE or DDF command, itterminates the transaction

Reference: 2RL.001.1 - Book 1 Section 7.3.4 - Mandatory data objects missing: DFName


� LT response to SELECT PSE or DDF does not contains DF Name Tag

Procedure: Application selection with PSE process is performed by the LT


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 mandatorySFI is missing in a response to SELECT PSE or DDF command, itterminates 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




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 mandatoryDDF Name is missing in a response to SELECT PSE or DDF command, itterminates the transaction.

Reference: 2RL.001.21 - Book 1 Section 8.2.3 - Mandatory data objects missing: DDFName


� LT response to SELECT PSE or DDF does not contain DDF Name



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 ADFName is missing in a response to SELECT ADF command

Reference: 2RL.001.3 - Book 1 Section 8.2.3 - Mandatory data objects missing: ADFName

Conditions: � LT response to SELECT ADF does not contains DF Name Tag

Procedure: Application selection process is performed by the LT




2CL.005.00 Mandatory data objects missing: ApplicationLabel

Test No. 2CL.005.00

Objective: To ensure that the terminal terminates the transaction if mandatoryApplication Label is missing from an ADF while the terminal is reading thePSE.

Reference: 2RL.001.4 - Book 1 Section 7.3.4 - Mandatory data objects missing:Application Label


� Application Label is missing from the ADF while the terminal reads thePSE



2CL.006.00 Mandatory data objects missing: FCI ProprietaryTemplate

Test No. 2CL.006.00

Objective: To ensure that the terminal terminates the transaction if mandatory FCIProprietary Template is missing in a response to SELECT command

Reference: 2RL.001.5 - Book 1 Section 7.3.4 - Mandatory data objects missing: FCIProprietary Template

Conditions: � LT response to SELECT does not contains FCI Proprietary TemplateTag





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 ismissing in a response to GET PROCESSING OPTIONS command

Reference: 2RL.001.6 - Book 3 Section 3.4 & Book 3 Section 3.3 - Mandatory dataobjects missing: AFL

Conditions: � LT response to GET PROCESSING OPTIONS does not contains AFL



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 ismissing in a response to GET PROCESSING OPTIONS command

Reference: 2RL.001.7 - Book 3 Section 3.4 & Book 3 Section 3.3 - Mandatory dataobjects missing: AIP

Conditions: � LT response to GET PROCESSING OPTIONS does not contains AIP





2CL.009.00 Mandatory data objects missing: CDOL1

Test No. 2CL.009.00

Objective: To ensure that the terminal terminates the transaction if mandatory CDOL1is missing in the card

Reference: 2RL.001.8 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory dataobjects missing: CDOL1

Conditions: � LT does not contains CDOL1



2CL.010.00 Mandatory data objects missing: CDOL2

Test No. 2CL.010.00

Objective: To ensure that the terminal terminates the transaction if mandatory CDOL2is missing in the card

Reference: 2RL.001.9 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory dataobjects missing: CDOL2

Conditions: � LT does not contains CDOL2





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 ismissing in the card

Reference: 2RL.001.10 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory dataobjects missing: PAN

Conditions: � LT does not contains PAN



2CL.012.00 Mandatory data objects missing: ApplicationExpiration Date

Test No. 2CL.012.00

Objective: To ensure that the terminal terminates the transaction if mandatoryApplication Expiration Date is missing in the card

Reference: 2RL.001.11 - Book 3 Section 3.4 & Book 3 Section 3.1 - Mandatory dataobjects missing: Application Expiration Date

Conditions: � LT does not contains Application Expiration Date





2CL.013.00 ATC not returned by GET DATA and Both LCOLand UCOL are present

Test No. 2CL.013.00

Objective: To ensure that terminal sets the ‘ICC data missing’ bit in the TVR to 1b ifboth Lower and Upper Consecutive Offline Limit data objects are present inthe 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 BothLCOL and UCOL are present

Conditions: � LT supports Terminal Risk Management (AIP Byte 1 bit 4 = '1')


� Lower and Upper Consecutive Offline Limit are present in LT











2CL.014.00 Last Online ATC Register not returned by GETDATA 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 ifboth Lower and Upper Consecutive Offline Limit data objects are present inthe 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 byGET DATA and Both LCOL and UCOL are present

Conditions: � LT supports Terminal Risk Management (AIP byte 1 bit 4= '1')


� Lower and Upper Consecutive Offline Limit are present in LT

� Last Online ATC is not returned by GET DATA










2CL.015.00 CVM List not present and Cardholder Verificationis supported in AIP

Test No. 2CL.015.00

Objective: To ensure that terminal sets the ‘ICC data missing’ bit in the TVR to 1b ifCardholder verification is supported in AIP and CVM List is missing in thecard.

Reference: 2RL.005.0 - Book 3 Section 3.4 - CVM List not present and CardholderVerification is supported in AIP

Conditions: � AIP byte 1 bit 5 = ‘1’ (Cardholder verification supported)

� CVM List is not present in LT







2CL.016.00 CA Public Key Index not present and Offline SDAis supported in AIP

Test No. 2CL.016.00

Objective: To ensure that terminal sets the ‘ICC data missing’ bit in the TVR to 1b ifOffline Static Data Authentication is supported in AIP and CertificationAuthority Public Key Index is missing in the card.

Reference: 2RL.006.0 - Book 3 Section 3.4 - Certification Authority Public Key Indexnot 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







2CL.017.00 CA Public Key Index not present and Offline DDAis supported in AIP

Test No. 2CL.017.00

Objective: To ensure that terminal sets the ‘ICC data missing’ bit in the TVR to 1b ifOffline Dynamic Data Authentication is supported in AIP and CertificationAuthority Public Key Index is missing in the card.

Reference: 2RL.007.0 - Book 3 Section 3.4 - Certification Authority Public Key Indexnot 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







2CL.019.00 Issuer Public Key Certificate not present andOffline 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 ifOffline Static Data Authentication is supported in AIP and Issuer Public KeyCertificate is missing in the card.

Reference: 2RL.009.0 - Book 3 Section 3.4 - Issuer Public Key Certificate not presentand Offline SDA is supported in AIP



� Issuer Public Key Certificate is not present in LT







2CL.020.00 Issuer Public Key Certificate not present andOffline 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 ifOffline Dynamic Data Authentication is supported in AIP and Issuer PublicKey Certificate is missing in the card.

Reference: 2RL.010.0 - Book 3 Section 3.4 - Issuer Public Key Certificate not presentand Offline DDA is supported in AIP



� Issuer Public Key Certificate is not present in LT







2CL.021.00 Issuer Public Key Exponent not present andOffline 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 ifOffline Static Data Authentication is supported in AIP and Issuer Public KeyExponent is missing in the card.

Reference: 2RL.011.0 - Book 3 Section 3.4 - Issuer Public Key Exponent not presentand Offline SDA is supported in AIP



� Issuer Public Key Exponent is not present in LT







2CL.022.00 Issuer Public Key Exponent not present andOffline 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 ifOffline Dynamic Data Authentication is supported in AIP and Issuer PublicKey Exponent is missing in the card.

Reference: 2RL.012.0 - Book 3 Section 3.4 - Issuer Public Key Exponent not presentand Offline DDA is supported in AIP



� Issuer Public Key Exponent is not present in LT







2CL.023.00 Issuer Public Key Remainder not present andOffline 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, ifOffline Static Data Authentication is supported in AIP and Issuer Public KeyRemainder is missing in the card and the length of the recovered IssuerPublic Key indicates that Issuer Public Key Remainder should be present.

Reference: 2RL.013.0 - Book 3 Section 3.4 - Issuer Public Key Remainder not presentand Offline SDA is supported in AIP



� Issuer Public Key Remainder is not present in LT

� Size of Issuer Public Key and CA Public Key is such as NI > NCA – 36







2CL.024.00 Issuer Public Key Remainder not present andOffline 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 , ifOffline Dynamic Data Authentication is supported in AIP and Issuer PublicKey Remainder is missing in the card and the length of the recoveredIssuer Public Key indicates that Issuer Public Key Remainder should bepresent.

Reference: 2RL.014.0 - Book 3 Section 3.4 - Issuer Public Key Remainder not presentand Offline DDA is supported in AIP



� Issuer Public Key Remainder is not present in LT

� Size of Issuer Public Key and CA Public Key is such as NI > NCA – 36







2CL.025.00 Signed Static Application Data not present andOffline 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 , ifOffline Static Data Authentication is supported in AIP and Signed StaticApplication Data is missing in the card.

Reference: 2RL.015.0 - Book 3 Section 3.4 - Signed Static Application Data notpresent and Offline SDA is supported in AIP



� Signed Static Application Data is not present in LT







2CL.026.00 ICC Public Key Certificate not present and OfflineDDA 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 , ifOffline Dynamic Data Authentication is supported in AIP and ICC PublicKey Certificate is missing in the card.

Reference: 2RL.016.0 - Book 3 Section 3.4 - ICC Public Key Certificate not presentand Offline DDA is supported in AIP



� ICC Public Key Certificate is not present in LT







2CL.027.00 ICC Public Key Exponent not present and OfflineDDA 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 , ifOffline Dynamic Data Authentication is supported in AIP and ICC PublicKey Exponent is missing in the card.

Reference: 2RL.017.0 - Book 3 Section 3.4 - ICC Public Key Exponent not present andOffline DDA is supported in AIP



� ICC Public Key Exponent is not present in LT







2CL.028.00 ICC Public Key Remainder not present and OfflineDDA 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 , ifOffline Dynamic Data Authentication is supported in AIP and ICC PublicKey Remainder is missing in the card and the length of the recovered ICCPublic Key indicates that ICC Public Key Remainder should be present.

Reference: 2RL.018.0 - Book 3 Section 3.4 - ICC Public Key Remainder not presentand Offline DDA is supported in AIP



� ICC Public Key Remainder is not present in LT

� Size of ICC Public Key and Issuer Public Key is such as NICC > NI – 42







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 PSEtemplate does not parse correctly, it terminates the processing.

Reference: 2RL.019.0 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: FCI of 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 awrong position...)


Pass Criteria: The terminal shall terminate processing and can return to applicationselection 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 notparse correctly, the terminal terminates the processing.

Reference: 2RL.019.07 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: Directory Record in Payment System Directory

Conditions: � Terminal supports SELECT PSE

� The Record returned in response to Read Directory command does notparse 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 applicationselection or abort the transaction.



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 templatedoes not parse correctly

Reference: 2RL.019.1 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: Record Template

Conditions: Record template returned in response to READ RECORD does not parsecorrectly (several tests can be made with bad Tag, bad length, Tag locatedat a wrong position...)



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 Applicationtemplate does not parse correctly in directory, it terminates the processing

Reference: 2RL.019.2 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: Application Template


� Application templates read in Directory file do not parse correctly(several tests can be made with bad Tag, bad length, Tag located at awrong position...)





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 ADFtemplate does not parse correctly

Reference: 2RL.019.3 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: FCI of ADF

Conditions: FCI of ADF template returned in response to SELECT ADF does not parsecorrectly (several tests can be made with bad Tag, bad length, Tag locatedat a wrong position...)



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 GETPROCESSING OPTIONS response template does not parse correctly

Reference: 2RL.019.4 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: GPO response template

Conditions: � GET PROCESSING OPTIONS response template returned in responseto GET PROCESSING OPTIONS does not parse correctly (several testscan be made with bad Tag, bad length, Tag located at a wrongposition...)


Pass Criteria: � The terminal shall terminate processing and can return to applicationselection or abort the transaction



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 ACresponse template does not parse correctly

Reference: 2RL.019.5 - Book 3 Section 3.4 & Section 2.5.5.4 - Constructed DataObjects do not parse correctly: Generate AC response template

Conditions: � GENERATE AC response template returned in response to GENERATEAC does not parse correctly (several tests can be made with bad Tag,bad length, Tag located at a wrong position...)



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 INTERNALAUTHENTICATE response template does not parse correctly

Reference: 2RL.019.6 - Book 3 Section 3.4 & Section 2.5.9.4 - Constructed DataObjects do not parse correctly: Internal Authenticate response template

Conditions: � INTERNAL AUTHENTICATE response template returned in response toINTERNAL AUTHENTICATE does not parse correctly (several tests canbe 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 (inparticular Dynamic Data Authentication)




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 bythe 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 severalmistakes: for instance day outside 01-31, month outside 01-12)



2CL.037.00 Data that must be in a specific range of values butare not: SFI

Test No. 2CL.037.00

Objective: To ensure that if the terminal supports selection with PSE and SFI valuereturned by the card in FCI is not in the range of supported values, itterminates the processing.

Reference: 2RL.021.0 - Book 1 Section 8.2.3 - Data that must be in a specific range ofvalues but are not: SFI


� SFI of Directory File returned by the LT is outside range 01-10





2CL.038.00 Data that must be in a specific range of values butare not: Issuer Code Table Index

Test No. 2CL.038.00

Objective: To ensure that the terminal terminates the processing if Issuer Code TableIndex 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 ina 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 ISO8959 supported values



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 doesnot contain any Cardholder Verification Rule

Reference: 2RL.022.0 - Book 3 Section 3.4 - CVM List with no Cardholder VerificationRules

Conditions: � CVM List in LT does not contain any Cardholder Verification Rule(empty)





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



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 AFLhas 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





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 recordnumber in AFL has a value of 0

Reference: 2RL.026.0 - Book 3 Section 3.4 - AFL with an incorrect starting recordnumber

Conditions: � Start record number in AFL has a value of 0



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 recordnumber in AFL has a value greater than the ending record

Reference: 2RL.027.0 - Book 3 Section 3.4 - AFL with an incorrect ending recordnumber

Conditions: � Start record number in AFL has a value greater than ending record





2CL.050.00 AFL with an incorrect number of recordsparticipating in Offline Data Authentication

Test No. 2CL.050.00

Objective: To ensure that the terminal terminates the processing if an entry in AFL hasan incorrect number of records participating in Offline Data Authentication.

Reference: 2RL.028.0 - Book 3 Section 3.4 - AFL with an incorrect number of recordsparticipating in Offline Data Authentication

Conditions: � Ending record number - start record number + 1< number of recordsparticipating in Offline Data Authentication



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 rightpadded 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 ismade with padding bytes 0x00 and 0xFF and for several templates: FCI,record...). Length of padding bytes is not included in the template length





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 ispadded 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 (beforethe template). Test is made with padding bytes 0x00 and 0xFF and forseveral templates: FCI, record...).



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 withbytes 0x00 or 0xFF between 2 Data Elements in a Template

Reference: 2RL.032.0 - Book 3 Section 1.2 - ISO Padding: padding between Dataobject

Conditions: � Some Data Templates returned by the LT contains padding betweenData Elements of the template. Test is made with padding bytes 0x00and 0xFF and for several templates: FCI, record...). Length of paddingbytes is included in the template length





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 duringInitiate Application Processing if PDOL includes amount field

Reference: 2RM.001.0 - Book 4 Section 2.3.1 - Merchant-controlled Terminal ProvidesAmount

Conditions: � PDOL requests Amount, Authorized


Pass Criteria: � The LT shall receive a GET PROCESSING OPTIONS with data fieldcontaining the amount of the transaction



2CM.002.00 Merchant-controlled Terminal Obtains Amount ifNot Available

Test No. 2CM.002.00

Objective: To ensure that the terminal displays the ‘Enter Amount’ message andobtains the amount of the transaction, during Initiate Application Processingif PDOL includes amount field and it is not yet available

Reference: 2RM.002.0 - Book 4 Section 2.3.1 - Merchant-controlled Terminal ObtainsAmount if Not Available

Conditions: � PDOL requests Amount, Authorized

� terminal is a merchant controlled terminal


Pass Criteria: � The LT shall receive a GET PROCESSING OPTIONS with data fieldcontaining the amount of the transaction

� The Terminal should display the ‘Enter Amount’ message

2CM.003.00 Card Returns Error in Response to GETPROCESSING Command

Test No. 2CM.003.00

Objective: To ensure that the terminal returns to application selection if the GETPROCESSING OPTIONS returns 69 85 for the selected application

Reference: 2RM.003.0 - Book 4 Section 2.3.1 - Card Returns Error in Response toGET PROCESSING Command

Conditions: � GET PROCESSING OPTIONS returns 69 85

� Terminal and LT have at least 2 mutually supported applications


Pass Criteria: � The LT shall receive a SELECT command for the next supportedapplication after having returned 69 85 to the GET PROCESSINGOPTIONS command



2CM.004.00 Online Only Terminal Not Supporting DataAuthentication Sets Bit

Test No. 2CM.004.00

Objective: To ensure that an online only terminal sets the ‘Offline Data Authenticationwas not performed’ bit in the TVR to 1b , if it does not support any form ofData authentication according to the Terminal capabilities

Reference: 2RM.004.0 - Book 4 Section 2.3.1 - Online Only Terminal Not SupportingData Authentication Sets Bit

Conditions: � Terminal capabilities indicates that Static and Dynamic DataAuthentication are not supported

� Terminal is online only terminal



Pass Criteria: � TVR byte 1, bit 8 = ‘1’ ie Data Authentication was not performed



2CM.006.00 Card and Terminal Application Version Numbersare different

Test No. 2CM.006.00

Objective: To ensure that if the card and terminal Application Version Numbers aredifferent, the terminal attempts to continue processing the transaction. If itis unable to continue, the terminal aborts the transaction.

Reference: 2RM.006.0 - Book 4 Section 2.3.3 - Card and Terminal Application VersionNumbers are different

Conditions: � LT and terminal have different Application Version Number



Pass Criteria: � The terminal shall attempt to process the transaction until completion, ifunable the terminal shall abort the transaction.

� TVR byte 2, bit 8 = ‘1’ ie ICC and terminal have different applicationversions



2CM.009.00 Terminal Recognition of CVM Codes ('No CVMrequired' supported)

Test No. 2CM.009.00

Objective: To ensure that the terminal recognizes CVM code ‘No CVM required’ if theterminal supports this CVM

Reference: 2RM.009.0 - Book 4 Section 2.3.4 - Terminal Recognition of CVM Codes.('No CVM required' supported)


� Terminal supports 'No CVM required'.

� CDOL1 requests TVR, TSI and CVM results

� CVM List is 'No CVM required, always'



� TVR byte 3, bit 8 = ‘0’ ie cardholder verification succeeded

� The terminal shall set byte 3 of the CVM Results to ‘successful’




2CM.009.05 Terminal Recognition of CVM Codes ('No CVMrequired' not supported)

Test No. 2CM.009.05

Objective: To ensure that the terminal recognizes CVM code ‘No CVM required’ if theterminal 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)


� Terminal does not support 'No CVM required'.

� CDOL1 requests TVR, TSI and CVM results

� CVM List is 'No CVM required, always'



� 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’




2CM.010.00 Terminal Recognition of CVM Codes ('Fail CVMprocessing')

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


� CVM List is 'Fail CVM, always'

� CDOL1 requests TSI and CVM Results



� The terminal shall set byte 3 of the CVM Results to ‘failed’


2CM.011.00 Supported CVM

Test No. 2CM.011.00

Objective: To ensure that CVM supported by the terminal are indicated in terminalcapabilities

Reference: 2RM.009.2 - Book 4 Section 2.3.4 - Supported CVM

Conditions: � PDOL requests Terminal capabilities



� Terminal capabilities returned by terminal shall reflect the CVMsupported by the terminal



2CM.012.00 PIN Try Counter

Test No. 2CM.012.00

Objective: To ensure that the terminal issue a GET DATA command to retrieve thePIN 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



� Test 1: CVM List is 'Plaintext PIN, always'

� Test 2: CVM List is 'Enciphered PIN, always'



� LT shall receive a GET DATA command (80 CA 9F 17) before receivingthe VERIFY command (test 1) or before receving a GET CHALLENGEcommand (test 2).



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 notretrievable or GET DATA is not supported by LT.

Reference: 2RM.011.0 - Book 4 Section 2.3.4.1 - PIN Try Counter Not Retrievable byICC




� LT does not return PIN Try Counter in response to GET DATA (PIN TryCounter)

� CVM List is 'Plaintext PIN, always'



� Terminal shall display the ‘Enter PIN’ message after having received theresponse to GET DATA command.



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 notretrievable 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



� 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'



� Terminal shall display the ‘Enter PIN’ message after having received theGET DATA command.



2CM.015.00 Terminal Behaviour When PIN Try Counter Equals0

Test No. 2CM.015.00

Objective: To ensure that the terminal sets the ‘PIN Try Limit exceeded’ in the TVR to1b, and continue the processing of CVM, if PIN Try counter returned byGET DATA is 0

Reference: 2RM.013.0 - Book 4 Section 2.3.4.1 - Terminal Behavior When PIN TryCounter Equals 0



� LT returns PIN Try Counter = 0 to GET DATA


� CVM List is 'Plaintext PIN, always' followed by 'Fail CVM , always'

� CDOL1 requests TSI, TVR and CVM Results



� Terminal shall not display any specific message regarding the PIN Trycounter.


� TVR byte 3, bit 8 = ‘1’ ie Cardholder verification was failed

� TSI byte 1 , bit 7 = '1' ie Cardholder verification was performed




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 messagesuch 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 (PINTry Counter >0)



� LT returns PIN Try Counter > 0 to GET DATA


� CVM List is Plaintext PIN always



� Terminal shall display the ‘Enter PIN’ message after having received theGET DATA command



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, ifoffline PIN verification by the ICC is successful

Reference: 2RM.015.0 - Book 4 Section 2.3.4.1 - CVM is Set When Offline PIN isSuccessful



� LT returns PIN Try Counter > 0 to GET DATA if Terminal supports GETDATA for PTC or VERIFY (9000)

� CVM List is Plaintext PIN always

� LT returns 90 00 to VERIFY

� CDOL1 requests CVM Results



� CVM Results Byte 3 = '02' (last CVM is successful)



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 theprocessing of CVM List, if offline PIN verification by the ICC is notsuccessful

Reference: 2RM.016.0 - Book 4 Section 2.3.4.1 - Offline PIN Not Successful



� LT returns PIN Try Counter > 0 to GET DATA if Terminal supports GETDATA 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



� TVR byte 3, bit 8 = ‘1’ ie Cardholder verification was failed

� TSI byte 1 , bit 7 = '1' ie Cardholder verification was performed CVMResults show 'Fail CVM, always, process is failed' as the last CVMprocessed ('00 00 01')



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 transmissionin 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


� Terminal supports Enciphered PIN verified Online

� CVM List is Enciphered PIN verified Online always



� Authorization or financial request message shall contain encrypted PIN



2CM.020.00 Online PIN When PIN Try Limit is Exceeded andTerminal 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 verificationeven if the card’s PIN Try Limit is exceeded

Reference: 2RM.018.0 - Book 4 Section 2.3.4.2 - Online PIN When PIN Try Limit isExceeded

Conditions: � Terminal supports Offline PIN (Plaintext or Enciphered)


� LT and Terminal support Cardholder verification


� CVM List requests ‘Plaintext PIN if terminal supports’ followed by‘Enciphered Offline PIN if terminal supports’ followed by ‘OnlineEnciphered PIN always.’ The first two CVR’s (Plaintext PIN andEnciphered 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




� 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




2CM.020.01 Online PIN When PIN Try Limit is Exceeded andthe 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 verificationeven if the card’s PIN Try Limit is exceeded

Reference: 2RM.018.0 - Book 4 Section 2.3.4.2 - Online PIN When PIN Try Limit isExceeded

Conditions: � Terminal supports Offline PIN (Plaintext or Enciphered)

� Terminal does not support GET DATA for PIN Try Counter

� LT and Terminal support Cardholder verification


� CVM List requests ‘Plaintext PIN if terminal supports’ followed by‘Enciphered Offline PIN if terminal supports’ followed by ‘OnlineEnciphered PIN always.’ The first two CVR’s (Plaintext PIN andEnciphered 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




� 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 OnlinePin entry




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’ whenPIN is entered for online verification

Reference: 2RM.019.0 - Book 4 Section 2.3.4.2 - CVM Results Set for Online PIN



� CVM is Enciphered PIN verified Online always

� CDOL1 requests CVM results



� CVM Results byte 3 shall be ‘unknown’



2CM.022.00 TVR is Set When PIN Entry is bypassed atAttended 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 Limitexceeded” bit in the TVR is not set to 1b, if an attended terminal bypassesPIN entry

Reference: 2RM.020.0 - Book 4 Section 2.3.4.3 - TVR is Set When PIN Entry isbypassed at Attended Terminal


� 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 signaturealways

* or Enciphered PIN online always

� Terminal has PIN bypass capabilities

� ‘Merchant’ forces the bypass of the PIN




� TVR byte 3, bit 4 = ‘1’ ie PIN entry required, PIN pad present, but PINwas not entered

� TVR byte 3, bit 6 = ‘0’ ie PIN Try Limit not exceeded



2CM.023.00 CVM unsuccessful When PIN Entry is bypassed atAttended Terminal

Test No. 2CM.023.00

Objective: To ensure that the terminal considers the CVM as unsuccessful andcontinue 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 isbypassed at Attended Terminal


� 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 signaturealways

* or Enciphered PIN online always

(with bit 7 of CVM code set to “Apply succeeding CVR is this CVM isunsuccessful)

� followed by another Cardholder Verification Rules (e.g. "No CVMrequired, always; signature, always…) supported by the terminal in orderto success the cardholder verification




� Terminal shall not display any specific message regarding the PIN Trycounter.




� 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 PINwas 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’ whensignature is the applicable CVM

Reference: 2RM.022.0 - Book 4 Section 2.3.4.4 - CVM is Set to ‘unknown’ WhenSignature is Used


� Terminal supports Signature

� CVM is Signature always




� CVM Results byte 3 shall be ‘unknown’



2CM.025.00 Terminal Prints Receipt With Line for CardholderSignature

Test No. 2CM.025.00

Objective: To ensure that the terminal prints a receipt with line for Cardholdersignature when signature is the applicable CVM

Reference: 2RM.023.0 - Book 4 Section 2.3.4.4 - Terminal Prints Receipt With Line forCardholder Signature


� Terminal supports Signature

� CVM is Signature always



� Terminal shall print a receipt with a line for Cardholder signature



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 isRequired


� Terminal supports 'No CVM required'

� CVM is 'No CVM required, always'




� 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’ whenapplicable CVM is Fail CVM

Reference: 2RM.025.0 - Book 4 Section 2.3.4.5 - CVM is Set When CVM is ‘Fail CVMProcessing’


� CVM is 'Fail CVM, always'




� CVM Results byte 3 shall be ‘failed’



2CM.028.00 CVM Results Set With Method Code andCondition Code of Last CVM Performed

Test No. 2CM.028.00

Objective: To ensure that the terminal sets the CVM Results bytes 1 and 2 accordingto the last CVM performed

Reference: 2RM.026.0 - Book 4 Section 2.3.4.5 - CVM Results Set With Method Codeand 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 ispresented OK

* Offline PIN always followed by Signature always and PIN notpresented OK

* Signature if supported CVM




� CVM Results byte 1 and 2 shall always be set in accordance with lastCVM performed in the list. for the example above content is:

* Offline PIN always

* Signature always

* Signature if supported CVM



2CM.029.00 CVM Results Set When Last CVM Not ConsideredSuccessful

Test No. 2CM.029.00

Objective: To ensure that the terminal sets the CVM Results byte 3 to ‘failed’ when thelast CVM performed was not considered as successful

Reference: 2RM.027.0 - Book 4 Section 2.3.4.5 - CVM Results Set When Last CVMNot Considered Successful


� 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




� CVM Results byte 3 shall be ‘failed’



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 CVMperformed’ 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 CVMWas Performed


� Test 1: no CVM list

� Test 2: CVM list but no satisfied conditions for instance Offline PIN ifsupported followed by signature if Amount under X and Terminal doesnot support PIN and Amount is over X




� CVM Results byte 1 shall be ‘no CVM performed’



2CM.031.00 Terminal Checks Presence of ApplicationSelected

Test No. 2CM.031.00

Objective: To ensure that if the terminal has an exception file, the terminal checks thepresence of the application selected in the exception file and does not setthe ‘Card appears in Exception file’ bit in the TVR to 1b, if no match isfound with the current PAN

Reference: 2RM.029.0 - Book 4 Section 2.3.5 - Terminal Checks Presence ofApplication Selected

Conditions: � Terminal supports exception file

� Exception File does not contain the PAN of LT




� TVR byte 1, bit 5 = ‘0’ ie Card does not appear in Exception file



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 inthe TVR to 1b, if Terminal has an exception file and a match is found withthe current PAN

Reference: 2RM.030.0 - Book 4 Section 2.3.5 - TVR Set if Match is Found in ExceptionFile

Conditions: � Terminal supports exception file

� Exception File contains the PAN of LT




� TVR byte 1, bit 5 = ‘1’ ie Card appears in Exception file



2CM.033.00 Authorization Response Code Set When TerminalAccepts Transaction Offline

Test No. 2CM.033.00

Objective: To ensure that the terminal sets Authorization Response Code to ‘Offlineapproved’ if result of Terminal Action Analysis is Offline

Reference: 2RM.031.0 - Book 4 Section 2.3.6 - Authorization Response Code SetWhen Terminal Accepts Transaction Offline

Conditions: � IAC and TAC are set so that Transaction is approved Offline




� Authorization Response Code shall be ‘Offline Approved’ whateverresponse of ICC

2CM.034.00 Authorization Response Code Set When TerminalDeclines Transaction Offline

Test No. 2CM.034.00

Objective: To ensure that the terminal sets Authorization Response Code to ‘DeclinedOffline’ if result of Terminal Action Analysis is to decline offline

Reference: 2RM.032.0 - Book 4 Section 2.3.6 - Authorization Response Code SetWhen Terminal Declines Transaction Offline

Conditions: � IAC and TAC are set so that Transaction is declined offline




� Authorization Response Code shall be ‘Declined Offline’



2CM.035.00 Authorization Response Code Not Set WhenTerminal Opts To Transmit Transaction Online

Test No. 2CM.035.00

Objective: To ensure that the terminal does not set Authorization Response Code toany 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 SetWhen Terminal Opts To Transmit Transaction Online

Conditions: � IAC and TAC are set so that Transaction is transmit online




� Authorization Response Code shall not be filled

2CM.036.00 Terminal Completes Transaction When CardIndicated Approval

Test No. 2CM.036.00

Objective: To ensure that the terminal completes the transaction if the card returnedan Approval to GENERATE AC

Reference: 2RM.034.0 - Book 4 Section 2.3.7 - Terminal Completes Transaction WhenCard Indicated Approval

Conditions: � LT returns TC to GENERATE AC (Test made with TC at firstGENERATE AC and at second GENERATE AC)





2CM.037.00 Terminal Declines Transaction When CardIndicated Denial

Test No. 2CM.037.00

Objective: To ensure that the terminal declines the transaction if the card returned aDecline to GENERATE AC

Reference: 2RM.035.0 - Book 4 Section 2.3.7 - Terminal Declines Transaction WhenCard Indicated Denial

Conditions: � LT returns AAC to GENERATE AC (Test made with AAC at firstGENERATE AC and at second GENERATE AC)



2CM.038.00 Terminal Transmits Auth. or Financial TransactionRequest Message

Test No. 2CM.038.00

Objective: To ensure that the terminal transmits a financial or authorization Requestmessage if the card indicates to process Online in response to GENERATEAC

Reference: 2RM.036.0 - Book 4 Section 2.3.7 - Terminal Transmits Auth. or FinancialTransaction Request Message

Conditions: � LT returns ARQC to GENERATE AC



� The Terminal shall format and transmit a financial or authorizationmessage



2CM.039.00 Terminal Performs Referrals if Card Indicates aReferral

Test No. 2CM.039.00

Objective: To ensure that the terminal performs a referral if the card indicates areferral in response to GENERATE AC

Reference: 2RM.037.0 - Book 4 Section 2.3.7 - Terminal Performs Referrals if CardIndicates a Referral

Conditions: � LT returns AAR to GENERATE AC



� The Terminal shall display a ‘Call Your Bank’ message

2CM.040.00 Advice is Requested by Card and is Supported bythe 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 itbut the transaction is captured

Reference: 2RM.038.0 - Book 4 Section 2.3.7 - Advice is Requested by Card and isSupported 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)



� The Terminal shall not transmit an advice message



2CM.041.00 Advice is Requested by Card and is Supported bythe 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 thetransaction is not captured

Reference: 2RM.039.0 - Book 4 Section 2.3.7 - Advice is Requested by Card and isSupported 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)



� The Terminal shall either prepare an offline advice message or transmitan 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 andterminates the transaction if the card indicates a ‘Service not allowed’ inresponse to GENERATE AC

Reference: 2RM.040.0 - Book 4 Section 2.3.7 - Terminal Terminates Transaction ifCard Indicates ‘Service Not Allowed’

Conditions: LT returns ‘Service not allowed’ in first GENERATE AC



� The Terminal should display a ‘Not accepted’ message



2CM.042.06 Combined DDA/AC Generation failed and ICCreturned an ARQC

Test No. 2CM.042.06

Objective: To ensure that if Combined DDA/AC Generation failed and if the cardreturns an ARQC, the terminal sets the 'Combined DDA/AC Generationfailed' bit in the TVR to 1b and completes the transaction by performingimmediately a second Generate AC requesting for an AAC.




� LT returns an ARQC in first Generate AC


Procedure: Application in LT is selected and transaction is processed with LT (inparticular Enhanced Combined DDA/AC Authentication).


� The terminal shall immediately perform a second Generate AC

� The terminal shall request for an AAC to the second Generate AC



� The terminal shall decline the transaction



2CM.043.00 Terminal Decides To Accept or DeclineTransaction and Issues 2nd GENERATE AC

Test No. 2CM.043.00

Objective: To ensure that the terminal issue a second GENERATE AC indicating thecontent of the Authorization Response Code, if transaction is processedonline

Reference: 2RM.041.0 - Book 4 Section 2.3.8 - Terminal Decides To Accept or DeclineTransaction and Issues 2nd GEN AC

Conditions: � Transaction is processed online

� Test 1: Issuer returns an Authorization Response Code indicatingacceptance

� Test 2: Issuer returns an Authorization Response Code indicatingdecline



� The LT shall receive a second GENERATE AC indicating TC for test 1and AAC for test 2



2CM.044.00 Authorization Response Code is ‘OnlineApproved’

Test No. 2CM.044.00

Objective: To ensure that the terminal transmit a reversal message, if transaction isprocessed online and transaction is captured online and AuthorizationResponse Code is ‘online approved’ and card returns AAC to secondGENERATE AC

Reference: 2RM.042.0 - Book 4 Section 2.3.8 - Authorization Response Code is‘Online Approved’


� Transactions are captured online (financial message)

� Authorization Response Code returned is ‘online approved’

� LT returns AAC to second GENERATE AC



� The Terminal shall format and transmit a Reversal Message



2CM.045.00 Terminal Support of Issuer Scripts inAuthorization or Financial Transaction Response

Test No. 2CM.045.00

Objective: To ensure that the terminal is able to manage and perform scripts if itreceives one or several scripts with the total length is less than or equal to128 bytes in authorization or financial response

Reference: 2RM.043.0 - Book 4 Section 2.3.9 - Terminal Support of Issuer Scripts inAuthorization or Financial Transaction Response


� Response contains one or several scripts with total length is 128 bytes



� The LT shall receive APDU commands according to the scripts sent inthe 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 resultsof scripts processed

Reference: 2RM.047.0 - Book 4 Section 2.3.9 - Terminal Reporting of Script Identifier


� Response contains one or several scripts with Tag 71 or 72 (tests canbe made with scripts that fail or succeed)



� Issuer Script Results (contained in Financial Confirmation message orBatch Data Captured message) shall match result of scripts sent to thecard (in particular scripts order, script Identifier, failure or success)



2CM.049.00 Issuer Script Results Set When Error Code WasReturned by Card

Test No. 2CM.049.00

Objective: To ensure that the terminal reports a script error in the Issuer ScriptResults.

Reference: 2RM.048.0 - Book 4 Section 2.3.9 - Issuer Script Results Set When ErrorCode Was Returned by Card


� Response contains one script

� LT returns an error to one of the command of the script (test can bemade with several sequence number for the command that fails)



� Issuer Script Results (contained in Financial Confirmation message orBatch Data Captured message) shall have first nibble of byte one set to‘Script Processing failed’ and the second nibble shall contain thesequence number of the command that failed)



2CM.050.00 Issuer Script Results Set When No Error CodeWas Returned by Card

Test No. 2CM.050.00

Objective: To ensure that the terminal reports a script success in the Issuer ScriptResults.

Reference: 2RM.049.0 - Book 4 Section 2.3.9 - Issuer Script Results Set When NoError Code Was Returned by Card


� Response contains one script

� LT returns 90 00 to all command of the script



� Issuer Script Results (contained in Financial Confirmation message orBatch Data Captured message) shall have first nibble of byte one set to‘Script Processing successful’ and the second nibble set to ‘0’



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 Datacapture Message or Financial Confirmation Message or Reversal Message

Reference: 2RM.050.0 - Book 4 Section 2.3.9 - Terminal Transmission of Issuer ScriptResults


� Response contains one or several scripts



� The terminal shall include Issuer Script Result in one of the followingmessage (Batch Data capture Message or Financial ConfirmationMessage or Reversal Message)



2CM.052.00 Terminal Creates an Advice When No Message isCreated for Transaction

Test No. 2CM.052.00

Objective: To ensure that the terminal creates an Advice message containing theIssuer Script Results if no message is created for the transaction (declinedtransaction)

Reference: 2RM.051.0 - Book 4 Section 2.3.9 - Terminal Creates an Advice When NoMessage is Created for Transaction

Conditions: � Terminal supports Advices

� Transaction is processed online

� Final GENERATE AC returns AAC

� Response contains one or several scripts



� The terminal shall create an Advice Message including Issuer ScriptResults



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 itsupports Dynamic Data Authentication

Reference: 2RM.054.0 - Book 4 Section 2.4 - Terminal Supporting DDA Shall SupportSDA

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



� Terminal Capabilities shall indicate Static Data Authentication support

� TVR byte 3, bit 7 = ‘0’ ie Static Data Authentication succeeded




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 offlineonly

Reference: 2RM.055.0 - Book 4 Section 2.4 - Offline Only Terminal Shall Support SDA


� Terminal is offline only











2CM.057.00 Offline Terminal With Online Capability ShallSupport SDA

Test No. 2CM.057.00

Objective: To ensure that the terminal supports Static Data Authentication if it is offlinewith online capabilities

Reference: 2RM.056.0 - Book 4 Section 2.4 - Offline Terminal With Online CapabilityShall Support SDA


� Terminal is offline with online capabilities











2CM.058.00 Offline Only Terminal Shall Support Terminal RiskManagement

Test No. 2CM.058.00

Objective: To ensure that the terminal supports Terminal Risk Management if it isoffline only

Reference: 2RM.057.0 - Book 4 Section 2.4 - Offline Only Terminal Shall SupportTerminal Risk Management

Conditions: � Terminal is Offline only














2CM.059.00 Offline Terminal With Online Capability ShallSupport Terminal Risk Management

Test No. 2CM.059.00

Objective: To ensure that the terminal supports Terminal Risk Management if it isoffline with online capabilities

Reference: 2RM.058.0 - Book 4 Section 2.4 - Offline Terminal With Online CapabilityShall Support Terminal Risk Management

Conditions: � Terminal is Offline with online capabilities














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 aFinancial institution Terminal

Reference: 2RM.059.0 - Book 4 Section 2.4 - Financial Institution Terminal SupportsTRM

Conditions: � Terminal is Financial institution Terminal (type 1x)





� CDOL1 requests TSI and TVR and Terminal Type









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 aMerchant Controlled Terminal

Reference: 2RM.060.0 - Book 4 Section 2.4 - Merchant Controlled Terminal SupportsTRM

Conditions: � Terminal is Merchant Controlled Terminal (type 2x)





� CDOL1 requests TSI and TVR and Terminal Type









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 thecardholder

Reference: 2RM.061.0 - Book 4 Section 2.5.1 - Terminal Displays Amount ofTransaction




� The Terminal shall indicate the Amount of transaction or print it on areceipt 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 BackAmount, if cash back is supported

Reference: 2RM.062.0 - Book 4 Section 2.5.1 - Cashback Amount is Transmitted in theAmount, 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



� Amount Other shall contain value entered for Cashback



2CM.064.00 Purchase and Cashback Transmitted in AmountAuthorised

Test No. 2CM.064.00

Objective: To ensure that the terminal include Purchase Amount and CashbackAmount in Amount Authorized

Reference: 2RM.063.0 - Book 4 Section 2.5.1 - Purchase and Cashback Transmitted inAmount Authorised

Conditions: � Terminal supports Cash Back


� CDOL1 requests Amount Authorized (in Numeric or Binary format), andAmount Other (in Numeric or Binary format)




� Amount Authorized shall be the sum of Cashback Amount and PurchaseAmount



2CM.066.00 Authorised Amount Is Expressed With ImplicitDecimal Point

Test No. 2CM.066.00

Objective: To ensure that the terminal stores Amount Authorized with Implicit DecimalPoint

Reference: 2RM.065.0 - Book 4 Section 2.5.1 - Authorized Amount Is Expressed WithImplicit Decimal Point

Conditions: � Purchase Amount has decimal values

� CDOL1 requests Amount Authorized



� Amount Authorized shall be expressed with implicit decimal point for thecurrency used



2CM.067.00 Other Amount Is Expressed With Implicit DecimalPoint

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 WithImplicit Decimal Point

Conditions: � Purchase Amount has decimal values

� Terminal supports Cash Back



� CDOL1 requests Amount Other



� Amount Other shall be expressed with implicit decimal point for thecurrency used



2CM.068.00 Attended Terminal Displays Message When CardRequests 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 MessageWhen Card Requests Voice Referral

Conditions: � Terminal is an attended terminal

� LT returns a Referral (AAR) in response to first GENERATE AC



� Terminal shall display the ‘Call your Bank’ message

2CM.069.00 Application Data Displayed or Printed To PerformReferral initiated by card

Test No. 2CM.069.00

Objective: To ensure that an attended terminal displays or prints appropriateapplication data like the PAN, if the card requests a Referral in theresponse to first GENERATE AC

Reference: 2RM.068.0 - Book 4 Section 2.5.2.1 - Application Data Displayed or PrintedTo Perform Referral initiated by card





� Terminal shall display or print PAN and other appropriate data



2CM.070.00 Messages Displayed For Attendant to IndicateApproval or Denial of a Referral initiated by card

Test No. 2CM.070.00

Objective: To ensure that an attended terminal displays a message requesting theattendant to enter the response from the Bank, if the card requests aReferral in the response to first GENERATE AC

Reference: 2RM.069.0 - Book 4 Section 2.5.2.1 - Messages Displayed For Attendant toIndicate Approval or Denial of a Referral initiated by card





� Terminal shall display a message requesting the attendant to enter theresponse from the Bank (after ‘Call your Bank’ and ‘data’ messages)



2CM.071.00 Authorization Response Code Set as a Result ofReferral Process initiated by card

Test No. 2CM.071.00

Objective: To ensure that an attended terminal sets the Authorization Response Codein accordance with response from the Bank entered if the card requests aReferral in the response to first GENERATE AC

Reference: 2RM.070.0 - Book 4 Section 2.5.2.1 - Authorization Response Code Set asa Result of Referral Process initiated by card




� Test 1: transaction approved by the Bank

� Test 2: transaction declined by the Bank



� Authorization Response Code shall be Approved for test 1 and declinedfor test 2



2CM.072.00 Terminal Issues Second GENERATE AC commandas 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 firstGENERATE AC, an attended terminal does not send EXTERNALAUTHENTICATE command and sends a second GENERATE ACcommand in accordance with response from the Bank entered

Reference: 2RM.071.0 - Book 4 Section 2.5.2.1 - Terminal Issues Second GENERATEAC command as a Result of Referral Process initiated by card







� LT shall not receive an EXTERNAL AUTHENTICATE command

� LT shall receive a second GENERATE AC command requesting a TCfor test 1 and an AAC for test 2



2CM.073.00 Terminal Behaviour When Transaction is ForcedOnline

Test No. 2CM.073.00

Objective: To ensure that if the card requests a Referral in the response to firstGENERATE AC and if the transaction is forced online, an attended terminaldoes not set the Authorization Response Code and transmits anAuthorization or Financial Request Message using the AAR as an ARQC

Reference: 2RM.072.0 - Book 4 Section 2.5.2.1 - Terminal Behavior When Transactionis Forced Online




� Transaction is forced online



� Authorization Response Code shall be filled according to the responsefrom the Issuer simulator

� The terminal shall transmit an Authorization or Financial RequestMessage containing the AAR instead of ARQC



2CM.074.00 Terminal Displays Message To Attendant WhenIssuer 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 ToAttendant When Issuer Requests Voice Referral


� Transaction is performed online (first GENERATE AC returns ARQC)

� Authorization Response Code returned in the response indicates a voiceReferral



� Terminal shall display the ‘Call your Bank’ message



2CM.075.00 Data Displayed or Printed to Perform Referralinitiated 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 printsappropriate application data like the PAN

Reference: 2RM.074.0 - Book 4 Section 2.5.2.2 - Data Displayed or Printed to PerformReferral initiated by issuer






� Terminal shall display or print PAN and other appropriate data



2CM.076.00 Messages Displayed Requesting Attendant toIndicate 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 messagerequesting the attendant to enter the response from the Bank

Reference: 2RM.075.0 - Book 4 Section 2.5.2.2 - Messages Displayed RequestingAttendant to Indicate Approval or Denial of a Referral initiated by issuer






� Terminal shall display a message requesting the attendant to enter theresponse from the Bank (after ‘Call your Bank’ and ‘data’ messages)



2CM.077.00 Authorization Response Code when Referral isinitiated 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 theAuthorization Response Code received

Reference: 2RM.076.0 - Book 4 Section 2.5.2.2 - Authorization Response Code whenReferral is initiated by Issuer







� Authorization Response Code shall be the same as the one receivedfrom issuer.



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 secondGENERATE AC command in accordance with response from the Bankentered manually

Reference: 2RM.077.0 - Book 4 Section 2.5.2.2 - Terminal Issues Second GENERATEAC








� LT may receive an EXTERNAL AUTHENTICATE command

� LT shall receive a second GENERATE AC command requesting a TCfor test 1 and an AAC for test 2



2CM.079.00 TVR Set When Merchant Forces TransactionOnline

Test No. 2CM.079.00

Objective: To ensure that if a transaction is forced online, an attended Terminal setsthe ‘Merchant forced transaction online’ bit in the TVR to 1b

Reference: 2RM.078.0 - Book 4 Section 2.5.3 - TVR Set When Merchant ForcesTransaction Online


� Transaction is forced online




� 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 terminaleither 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 theTransaction


� Attendant forces acceptance of the transaction (test is made with severalresponse from LT)



� The Terminal shall either send online financial advice or create a batchdata capture entry



2CM.081.00 Authorization Response Code when acceptance isforced

Test No. 2CM.081.00

Objective: To ensure that if attendant forces the approval of a transaction, the terminaldoes not modify the Authorization Response Code

Reference: 2RM.080.0 - Book 4 Section 2.5.4 - Authorization Response Code whenacceptance is forced


� Transaction is performed online

� Attendant forces acceptance of the transaction



� Authorization Response Code in online financial advice or in batch datacapture entry shall be the same as the one received from Issuer



2CM.082.00 Terminal Sets Indicator When Attendant forcesApproval of the Transaction

Test No. 2CM.082.00

Objective: To ensure that the terminal sets an indicator in the online advice or batchdata capture if the attendant forced acceptance of the transaction.

Reference: 2RM.081.0 - Book 4 Section 2.5.4 - Terminal Sets Indicator WhenAttendant forces Approval of the Transaction


� Transaction is performed online

� Attendant forces acceptance of the transaction



� The terminal shall set an indicator in the online advice or batch datacapture that the attendant forced acceptance of the transaction

2CM.083.00 Terminal Maintains Transaction SequenceCounter

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 TransactionSequence Counter

Conditions: � Several Transaction are performed

� CDOL1 requests Transaction Sequence Counter


Pass Criteria: � The terminal shall process the transaction until completion for eachtransaction

� Transaction Sequence Counter shall be incremented by one at eachtransaction



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


Pass Criteria: � The terminal shall process the transaction until completion for eachtransaction

� Unpredictable Number shall be different at each transaction

2CM.086.00 Terminal Reading of Service Code on MagneticStripe

Test No. 2CM.086.00

Objective: To ensure that the terminal displays a message ‘Use Chip Reader’ if themagstripe is read and the Service Code begins with ‘2’ or ‘6’, and if theterminal does not have a combined IC and magnetic stripe reader.

Reference: 2RM.085.0 - Book 4 Section 2.6 - Terminal Reading of Service Code onMagnetic 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



2CM.087.00 Terminal Reading of Service Code on MagneticStripe

Test No. 2CM.087.00

Objective: To ensure that the terminal switch to IC process if the magstripe is readand the Service Code begins with ‘2’ or ‘6’

Reference: 2RM.086.0 - Book 4 Section 2.6 - Terminal Reading of Service Code onMagnetic 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 toLT



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 magstripeand Service code begins with ‘2’ or ‘6’, the terminal set POS entry modecode to ‘Magnetic Stripe read, last transaction was an unsuccessful ICread’ 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 thePOS entry mode code set to ‘Magnetic Stripe read, last transaction wasan unsuccessful IC read’



2CM.092.00 Calculation of Dates Associated With DataAuthentication

Test No. 2CM.092.00

Objective: To ensure that the terminal is capable of properly calculate date associatedwith 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 WithData Authentication



� Issuer Public Key Certificate in LT is calculated with different CertificateExpiration Dates (several tests):

* Certificate Expiration Dates before year 2000

* Certificate Expiration Dates in year 2000

* Certificate Expiration Dates after year 2000




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



2CM.093.00 Calculation of Dates Associated With ProcessingRestrictions

Test No. 2CM.093.00

Objective: To ensure that the terminal is capable of properly calculate date associatedwith processing restrictions for dates before, including, and after the year2000

Reference: 2RM.093.0 - Book 4 Section 2.7.2 - Calculation of Dates Associated WithProcessing 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



� TVR byte 2, bit 7 shall be set according to the Application ExpirationDates (‘1’ if after the current date, ‘0’ if before the current date)

� TVR byte 2, bit 6 shall be set according to the Application EffectiveDates (‘0’ if before the current date, ‘1’ if after the current date)



2CM.094.00 Calculation, Storage, and Display Date-DependantFields For Year 2000 +

Test No. 2CM.094.00

Objective: To ensure that the terminal is able to accurately calculate and store datedependent fields representing the year 2000

Reference: 2RM.094.0 - Book 4 Section 2.7.3 - Calculation, Storage, and Display Date-Dependant 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



� Transaction Date shall have been updated to correct value:

* 01/01/2000

* 29/02/2000



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




� TVR byte 2, bit 7 shall be set according to the Application ExpirationDates (‘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 ifthese colors are used on the device

Reference: 2RM.096.0 - Book 4 Section 3.1.1 - Coloring of Command Keys


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



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 thenumeric and ‘Enter’ and ‘Cancel’ command keys

Reference: 2RM.099.0 - Book 4 Section 3.1.2 - Numeric and Command Keys on PINPad

Conditions: � Terminal is equipped with a PIN Pad


Pass Criteria: � PIN Pad shall comprise the numeric and ‘Enter’ and ‘Cancel’ commandkeys

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 numericlayout of the PIN pad complies with ISO 9564, except for cardholder-controlled 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


Pass Criteria: � PIN Pad numeric layout shall comply with ISO 9564



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 AttendedTerminal

Conditions: � Terminal is attended terminal


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 atleast 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


Pass Criteria: � Display shall be capable of displaying at least 32 alphanumericcharacters (two lines of 16 positions each).



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 partof the terminal, including cryptographic keys, are not erased or altered forthe period of time the software and data are valid.

Reference: 2RM.104.0 - Book 4 Section 3.3 - Protection of Software and Data


Procedure: Visual inspection by the tester is required in the terminal data bases

Pass Criteria: � Terminal software, data initialized and cryptographic keys shall not beerased 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 AdvicesStored

Test No. 2CM.105.00

Objective: To ensure that when the terminal supports batch data capture, the capturedtransactions and advices stored in the terminal are not erased or altereduntil the next reconciliation with the acquiring system.

Reference: 2RM.105.0 - Book 4 Section 3.3 - Protection of Captured Transactions andAdvices 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 beerased or altered.



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 onlinecapability 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 20alphanumeric 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


Pass Criteria: � PAN shall be printed correctly on the receipt



2CM.108.00 Terminal Also Equipped With Magnetic StripeReader

Test No. 2CM.108.00

Objective: To ensure that terminal is also equipped with a Magstripe Reader exceptfor cardholder controlled terminal or if Payment System rules indicatesotherwise

Reference: 2RM.108.0 - Book 4 Section 3.6 - Terminal Also Equipped With MagneticStripe Reader

Conditions: � Terminal is not a cardholder controlled terminal

� Payment System rules do not indicate that magstripe reader is notrequired

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/orTrack 2

Test No. 2CM.109.00

Objective: To ensure that if present, terminal Magstripe Reader is able to read fulltrack 1 and /or track 2

Reference: 2RM.109.0 - Book 4 Section 3.6 - Magnetic Stripe Reader Using Full Track1 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



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-12Digit PIN



� CVM in LT is Plaintext PIN verification performed by ICC always orEnciphered PIN verification performed by ICC always

� PIN in LT has various length between 4 and 12 and is presented OK






� PIN received by LT shall be OK



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 theentry of each digit shall be displayed

Reference: 2RM.130.0 - Book 2 Section 11.1.2 - Display of Indication of Entry on PINPad



� CVM in LT is Plaintext PIN verification performed by ICC always



� An indication of the entry of each digit shall be displayed



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 theentered PIN are not displayed or disclosed by visible or audible feedbackmeans, in accordance with ISO 9564-1

Reference: 2RM.131.0 - Book 2 Section 11.1.2 - Protection of Values of Entered PIN






� The value of the entered PIN shall not be displayed

� The value of the entered PIN shall not be disclosed by audible feedbackmeans



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 ISO9564-1 and transmits it according to the payment system’s rules, if theterminal supports online PIN verification

Reference: 2RM.137.0 - Book 2 Section 11.1.2 - Protection of PIN During Online PINVerification


� Terminal supports enciphered PIN verified online

� CVM in LT is enciphered PIN verified online always

� PIN is presented OK



� The enciphered PIN Data in financial or authorization request messageshall contain the PIN entered enciphered according to ISO 9564-1



2CM.140.00 Amount Entry Process Separate From PIN EntryProcess

Test No. 2CM.140.00

Objective: To ensure that if the Terminal is attended and supports PIN entry, theamount entry process is separate from the PIN entry process

Reference: 2RM.141.0 - Book 2 Section 11.1.2 - Amount Entry Process Separate FromPIN Entry Process


� Terminal is attended terminal





� The amount entry process shall be separated from the PIN entryprocess to avoid any accidental display of a PIN on the terminal display



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 entryof the PIN if the Terminal is attended and supports PIN entry and Amountand PIN are entered on the same key pad

Reference: 2RM.142.0 - Book 2 Section 11.1.2 - Amount Validated by Cardholder


� Terminal is attended terminal


� Amount and PIN are entered on the same key pad




� The amount entry process shall be validated before the terminalswitches to PIN entry



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 secondgenerate AC, the terminal declines the transaction.




� LT returns an ARQC in first Generate AC

� Enhanced Combined DDA/AC signature generated in LT is good for the1st Generate AC response


Pass Criteria: � The terminal shall decline the transaction after the 2nd Generate AC.





2CM.143.00 Combined DDA/AC generation requested bit inGenerate AC

Test No. 2CM.143.00

Objective: To ensure that the terminal sets the combined DDA/AC requested bit to 1bin generate AC if enhanced combined DDA/AC is to be performed





� In GENERATE AC command, bit 6 of P1 is set to 1b (i.e. EnhancedCombined DDA/AC generation requested)



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 3Annex Aare initialized in the terminal or obtainable at the time of atransaction

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 toreturn 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



� 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


� Data Element returned by the terminal shall have correct format andcoherent value

� Acquirer Identifier n 6-11

� Additional Terminal Capabilities b

� Amount Authorized b or n 12

� Amount Other b or n 12

� Amount Reference Currency b

� Application Identifier b

� Application Version Number b

� CVM Results b

� Certification Authority Public Key Index b

� Interface Device Serial Number an 8

� Merchant Category Code n 4

� Merchant Identifier ans 15

� POS Entry Mode n 2

� Terminal Capabilities b

� Terminal Country Code n 3

� Terminal Floor Limit b

� Terminal identification an 8

� Terminal Risk Management Data b

� Terminal Type n 2

� Terminal Verification Results b

� Transaction Currency Code n 3



� Transaction Currency Exponent n 1

� Transaction Date n 6 (YYMMDD)

� Transaction Reference Currency Code n 3

� Transaction Reference Currency Exponent n 1

� Transaction Sequence Counter n 4-8

� Transaction Status Information b

� Transaction Time n 6 (HHMMSS)

� Transaction Type n 2

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 identifywhat language(s) are supported to process the card’s LanguagePreference

Reference: 2RN.012.0 - Book 4 Section 6.1 - Language Supported by Terminal

Conditions: � Several LTs have different Language Preference



� The languages supported by the terminal shall be used if requested byLT in Language Preference



2CN.016.00 Terminal Displays Error Message if VerificationProcess fails

Test No. 2CN.016.00

Objective: To ensure that if operator action is needed, the terminal displays an errormessage if the verification process fails during the loading of theCertification Authority Public Key

Reference: 2RN.016.0 - Book 4 Section 6.2 - Terminal Displays Error Message ifVerification 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 thelanguage of common usage in the terminal’s 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 terminal’s locality orregion

� Terminal has a display



� The message displayed shall be in the language of common usage inthe terminal’s locality or region shall be used



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 thelanguage of common usage in the terminal’s locality or region

Reference: 2RO.002.0 - Book 4 Section 7.1 - Terminal Display of Messages in LocalLanguage

Conditions: � Terminal is attended and has a display



� The message displayed for the attendant shall be in the language ofcommon usage in the terminal’s 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 relevantcharacter set defined in the corresponding part of ISO 8859

Reference: 2RO.003.0 - Book 4 Section 7.1 - Terminal Support of Relevant CharacterSet

Conditions: � Several LTs have different Language Preference



� The languages supported by the terminal (and the LT) shall be used withrelevant character set



2CO.005.00 Terminal uses language With Highest Preference

Test No. 2CO.005.00

Objective: To ensure that the terminal compare the card’s Language Preference withthe languages supported in the terminal at the beginning of the transactionand uses the language with the highest preference in the messagesdisplayed to the cardholder if a match is found.

Reference: 2RO.005.0 - Book 4 Section 7.1 - Terminal uses language With HighestPreference

Conditions: � Terminal supports several Languages

� Several LTs have different Language Preference value with at least onematching language with Terminal (Language Preference is coded so thatlanguage with highest priority appears first)



� The messages for the cardholder shall be displayed in the Languagewith highest priority supported by both LT and Terminal



2CO.006.00 Terminal Allows Cardholder to Select Language

Test No. 2CO.006.00

Objective: To ensure that the terminal compare the card’s Language Preference withthe languages supported in the terminal at the beginning of the transactionand allows the cardholder to choose if no match is found and Terminalsupports several Languages

Reference: 2RO.006.0 - Book 4 Section 7.1 - Terminal Allows Cardholder to SelectLanguage


� LT have Language Preference value with no matching language withTerminal



� The Terminal shall ask the cardholder to choose his favourite Language



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 Cardholderif a Language selection by cardholder occurred

Reference: 2RO.007.0 - Book 4 Section 7.1 - Terminal Displays Message in SelectedLanguage





� The Terminal shall ask the cardholder to choose his favourite Language

� The messages for the Cardholder shall be displayed in the selectedLanguage



2CO.008.00 Terminal Displays Message in SupportedLanguage

Test No. 2CO.008.00

Objective: To ensure that the terminal uses the language it supports if no match isfound with card supported Languages and Terminal supports only oneLanguage (Language of common usage in the region)

Reference: 2RO.008.0 - Book 4 Section 7.1 - Terminal Displays Message in SupportedLanguage

Conditions: � Terminal supports only one Language




� The messages for the Cardholder shall be displayed in the Terminalsupported 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



� The LT shall receive a SELECT command for each of the terminalsupported application



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 aredisplayed using the Application Preferred Name if the terminal supportscardholder application selection and if Application Preferred Name ispresent 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 ApplicationsSupported (1)

Conditions: � LT and Terminal have several mutually supported applications

� LT applications have a priority order specified in Application PriorityIndicator

� Terminal supports selection of application by the Cardholder

� LT applications have Application Preferred Name and Issuer Code TableIndex



� The Terminal shall display the list of applications mutually supportedusing the Application preferred Name and corresponding Issuer TableIndex for each Application



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 aredisplayed using the Application Label if the terminal supports cardholderapplication selection and if Application Preferred Name is absent

Reference: 2RO.013.1 - Book 4 Section 7.3 - Terminal Creates a List of ApplicationsSupported (2)

Conditions: � LT and Terminal have several mutually supported applications


� Terminal supports selection of application by the Cardholder

� LT applications have not Application Preferred Name



� The Terminal shall display the list of applications mutually supportedusing the Application Label and common Issuer Table Index



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 responseto the SELECT command, a terminal allowing cardholder selection orconfirmation should display the ‘Try again’ message and presents to thecardholder the list of applications supported by both the ICC and theterminal 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 FinalSELECT command


Pass Criteria: � The terminal shall present to the cardholder the list of all applicationssupported by both the ICC and the terminal without this application.

� The terminal should display the ‘Try again’ message.



2CO.016.00 Terminal Selects Application With Next Highestpriority

Test No. 2CO.016.00

Objective: To ensure that if the terminal does not support cardholder applicationselection, and if selected application returned status different from 90 00, itselects the application with second priority from the list of applicationmutually supported by card and terminal and not requiring cardholderconfirmation

Reference: 2RO.016.0 - Book 4 Section 7.3 - Terminal Selects Application With NextHighest priority

Conditions: � LT and Terminal have several mutually supported applications (at least3)


� Terminal does not support selection of application by the Cardholder

� Application with highest priority in the list of mutually supportedapplications requires Cardholder confirmation

� LT returns status different from 9000 to the SELECT command sent toselect Application with second highest priority in the list of mutuallysupported applications (the SELECT command sent for this applicationduring the phase where terminal looks for mutually supported applicationworks correctly)



� After the phase where terminal looks for the applications present in thecard, the LT shall receive a SELECT command for the application withsecond highest priority in the list of mutually supported application andLT shall return status different from 90 00

� The LT shall receive another SELECT command for the application withthird highest priority in the list of mutually supported application



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, ifallowed 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



� The terminal shall print a receipt with partial Application PAN (or the fullPAN, 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 thereceipt

Reference: 2RO.018.0 - Book 4 Section 7.3 - Data Printed on Receipt

Conditions: � Terminal is equipped with a printer



� The terminal shall print a receipt with the AID in hexadecimal characters



2CO.019.00 Authorization Message Used

Test No. 2CO.019.00

Objective: To ensure that the terminal uses an authorization message whentransactions 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



� The terminal shall prepare and transmit an authorization requestmessage

2CO.020.00 Financial Transaction Message Used

Test No. 2CO.020.00

Objective: To ensure that the terminal uses a Financial Transaction message whenonline data capture is performed by the acquirer

Reference: 2RO.021.0 - Book 4 Section 8.1 - Financial Transaction Message Used


� Terminal supports online data capture



� The terminal shall prepare and transmit a financial transaction message



2CO.021.00 Offline Advice message Conveyed

Test No. 2CO.021.00

Objective: To ensure that the terminal conveys offline advices within batch datacapture when supported.

Reference: 2RO.022.0 - Book 4 Section 8.1 - Offline Advice message Conveyed

Conditions: � Terminal supports batch data capture.


� LT requests an Advice in response to First GENERATE AC


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



� The terminal shall prepare and transmit a Reversal



2CO.025.00 Terminal Issues a 2nd GENERATE AC CommandWhen Unable to Go Online (1)

Test No. 2CO.025.00

Objective: To ensure that the terminal set Authorization Response Code to ‘Unable togo online, offline accepted’ and issues a second GENERATE AC indicatingTC if the terminal accepts the transaction after not having been able to goonline

Reference: 2RO.025.0 - Book 4 Section 8.2.1 - Terminal Issues a 2nd GENERATE ACCommand When Unable to Go Online (1)

Conditions: � Terminal Action Codes and Issuer Action Code Denial and Online haveall bits set to 0b

� Issuer Actions Codes Default have all bits set to 0b


� Terminal is unable to go online (no response received from issuer forinstance)

� CDOL2 requests Authorization response Code



� The LT shall receive a second GENERATE AC command requesting aTC

� Authorization response Code shall contain to ‘Unable to go online, offlineaccepted’



2CO.026.00 Terminal Issues a 2nd GENERATE AC CommandWhen Unable to Go Online (2)

Test No. 2CO.026.00

Objective: To ensure that the terminal set Authorization Response Code to ‘Unable togo online, offline declined and issues a second GENERATE AC indicatingAAC if the terminal declines the transaction after not having been able to goonline

Reference: 2RO.026.0 - Book 4 Section 8.2.1 - Terminal Issues a 2nd GENERATE ACCommand When Unable to Go Online (2)


� 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 IssuerAction Code Default are set to 1b in the TVR during transactionprocessing (several tests can also be made for different bits set)


� Terminal is unable to go online (no response received from issuer forinstance)




� The LT shall receive a second GENERATE AC command requesting anAAC

� Authorization response Code shall contain to ‘Unable to go online, offlinedeclined’



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 AUTHENTICATEcommand to the card and sets the ‘Issuer authentication was performed’ bitin the Transaction Status Information to ‘0’, if response received does notcontain the Issuer Authentication Data

Reference: 2RO.027.0 - Book 4 Section 8.2.2 - Issuer Authentication was performed’Bit is Set



� Response from Issuer does not contain Issuer Authentication Data




� The LT shall not receive an EXTERNAL AUTHENTICATE command

� TSI byte 1, bit 5 = ‘0’ ie the Issuer Authentication was not performed



2CO.028.00 Terminal Continues Processing Based onAuthorization Response Code

Test No. 2CO.028.00

Objective: To ensure that the terminal continue the processing of the transactionaccording to the Authorization Response Code if transaction is performedonline.

Reference: 2RO.028.0 - Book 4 Section 8.2.2 - Terminal Continues Processing Basedon Authorization Response Code




� 4 values of Authorization Response Code are tested

1. Online approved

2. Online declined

3. Referral



� Authorization Response Code shall be the same as the one receivedfrom 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



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 goonline if it has repeated the authorization request and the authorizationresponse received is still incorrect.

Reference: 2RO.029.0 - Book 4 Section 8.2.3 - Repeat of Authorization Request








� Terminal shall repeat the authorization request after incorrect or absentresponse




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 togo online, offline accepted’ and issues a second GENERATE AC indicatingTC if it has repeated the authorization request and the authorizationresponse received is still incorrect and if the terminal accepts thetransaction.

Reference: 2RO.030.0 - Book 4 Section 8.2.3 - Terminal Issues a 2nd GENERATE ACCommand (1)


� Issuer Actions Codes Default have all bits set to 0








� Authorization Response Code shall contain to ‘Unable to go online,offline accepted’



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 togo online, offline declined' and issues a second GENERATE AC indicatingAAC if it has repeated the authorization request and the authorizationresponse received is still incorrect if the terminal declines the transaction.

Reference: 2RO.031.0 - Book 4 Section 8.2.3 - Terminal Issues a 2nd GENERATE ACCommand (2)











� Authorization response Code shall contain to ‘Unable to go online, offlinedeclined’



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 onlinedata capture is performed and the terminal has repeated the authorizationrequest and the authorization response received is still incorrect.

Reference: 2RO.032.0 - Book 4 Section 8.2.3 - Terminal Sends Reversal Message






� The terminal shall prepare and transmit a Reversal message in theformat described in Book 4 - Tables 14 and 15



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 beensent 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 haveall bits set to 0b

� Issuer Actions Codes Default have all bits set to 0b



� The LT shall return a TC to the second GENERATE AC command





� The terminal shall prepare Financial message in the format described inBook 4 - Tables 14 and 15



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 isa script length error or syntax error.

Reference: 2RO.034.0 - Book 4 Section 8.2.4 - Terminal Terminates Processing ofIssuer Script


� Issuer sends scripts:

* Test 1: script has a script length error (total length is larger thansupported length)

* Test 2: script has a syntax error and it is not possible to parse thescript into single script commands



� The LT shall not receive any command of script for test 1 and 2



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 doesnot parse correctly and reports scripts error in Issuer Script Results

Reference: 2RL.019.8 - Book 1 Section 6 - Constructed Data Objects do not parsecorrectly: Issuer Script

2RO.036.0 - Book 4 Section 8.2.4 - Terminal Reports in Issuer Scriptresults


� Authorization or financial response contains one or several scripts whichdoes not parse correctly

� Issuer sends script which has a syntax error and it is not possible toparse the script into single script commands (several tests can be madewith bad Tag, bad length, Tag located at a wrong position...)

� Script received has a readable Script Identifier



� The terminal shall terminate the bad parsed Issuer script processing andcontinue subsequent Scripts if readable

� Issuer Script Results (contained in Financial Confirmation message orBatch Data Captured message) shall not perform the script.



2CO.036.00 Terminal Continues Processing any SubsequentIssuer Script

Test No. 2CO.036.00

Objective: To ensure that the terminal continues processing of any subsequent scriptif the script currently processed has a syntax error.

Reference: 2RO.037.0 - Book 4 Section 8.2.4 - Terminal Continues Processing anySubsequent Issuer Script


� Issuer sends back 2 scripts:

* script 1 has a syntax error and it is not possible to parse the scriptinto single script commands

* script 2 is good



� The LT shall receive command for script 2 only



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 itseffective type.

Reference: 2RP.001.0 - Book 4 Annex A - Terminal Type

Conditions: CDOL1 requests Terminal Type and Terminal Capabilities


Pass Criteria: � Terminal capabilities shall be coded according to the terminal supportedfeatures indicated below:

* Attended Terminal x1 or x2 or x3

* Unattended Terminal x4 or x5 or x6

* Terminal operated by Financial Institutions 1x

* Terminal operated by Merchant 2x

* Terminal operated by Cardholder 3x

* Online only x1 or x4

* Offline with online capabilities x2 or x5

* Offline only x3 or x6



2CP.002.00 Terminal Capabilities

Test No. 2CP.002.00

Objective: To ensure that the terminal has Terminal capabilities coded according to itseffective Capabilities

Reference: 2RP.002.0 - Book 4 Annex A - Terminal Capabilities

Conditions: CDOL1 requests Terminal Capabilities


Pass Criteria: � Terminal capabilities shall be coded according to the terminal supportedfeatures indicated below:

* Manual Key entry byte 1, b8 = 1

* Magnetic stripe byte 1, b7 = 1

* IC with contacts byte 1, b6 = 1

* Plaintext PIN verified by ICC byte 2, b8 = 1

* Enciphered PIN online byte 2, b7 = 1

* Signature byte 2, b6 = 1

* Offline Enciphered PIN verified by ICC byte 2, b5 = 1

* No CVM required byte 2, b4 = 1

* Static Data Authentication byte 3, b8 = 1

* Dynamic Data Authentication byte 3, b7 = 1

* Card capture byte 3, b6 = 1



2CP.003.00 Additional Terminal Capabilities

Test No. 2CP.003.00

Objective: To ensure that the terminal has Additional Terminal capabilities codedaccording to its effective Capabilities

Reference: 2RP.003.0 - Book 4 Annex A - Additional Terminal Capabilities

Conditions: CDOL1 requests Additional Terminal Capabilities


Pass Criteria: � Transaction Type Capabilities shall be coded according to the terminalsupported features indicated below:

* Cash byte 1, b8 = 1

* Goods byte 1, b7 = 1

* Services byte 1, b6 = 1

* Cashback byte 1, b5 = 1

* Inquiry byte 1, b4 = 1

* Transfer byte 1, b3 = 1

* Payment byte 1, b2 = 1

* Administrative byte 1, b1 = 1

* Numeric Keys byte 3, b8 = 1

* Alphabetical and special characters keys byte 3, b7 = 1

* Command Keys byte 3, b6 = 1

* Function Keys byte 3, b5 = 1

* Print, attendant byte 4, b8 = 1

* Print, cardholder byte 4, b7 = 1

* Display, attendant byte 4, b6 = 1

* Display, cardholder byte 4, b5 = 1

* Code table 10 byte 4, b2 = 1



* Code table 9: byte 4, b1 = 1



* Code table 6 byte 5, b6 = 1






< End Of The Document>