D-PAS Card Specification v1.1

D-PAS
CARD SPECIFICATION
DISCOVER FINANCIAL SERVICES
Issued Date: March 24, 2010

Version 1.1
Proprietary and Confidential

©2009 DFS Services LLC
D-PAS Card Specification
DISCLAIMER
This Specification is provided "AS IS" "WHERE IS" and "WITH ALL FAULTS". Neither
Discover Financial Services, nor Diners Club International Ltd., nor any of their affiliates,
subsidiaries, directors, officers or employees (collectively, the “DFS Parties”) assume or
accept any liability for any errors or omissions contained in the Specification.
THE DFS PARTIES MAKE NO REPRESENTATIONS OR WARRANTIES OF ANY KIND,

EXPRESS OR IMPLIED, WITH RESPECT TO THE SPECIFICATION. THE DFS PARTIES
SPECIFICALLY DISCLAIM ALL REPRESENTATIONS AND WARRANTIES, INCLUDING THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE DFS PARTIES FURTHER SPECIFICALLY DISCLAIM ALL REPRESENTATIONS
AND WARRANTIES WITH RESPECT TO INTELLECTUAL PROPERTY SUBSISTING IN OR
RELATING TO THE SPECIFICATION OR ANY PART THEREOF, INCLUDING BUT NOT
LIMITED TO ANY AND ALL IMPLIED WARRANTIES OF TITLE, NON-INFRINGEMENT OR
SUITABILITY FOR ANY PURPOSE (WHETHER OR NOT THE DFS PARTIES HAVE BEEN
ADVISED, HAVE REASON TO KNOW, OR ARE OTHERWISE IN FACT AWARE OF ANY
INFORMATION).
For the avoidance of doubt, the DFS Parties make no representation or warranty
regarding whether any particular physical implementation of any part of this Specification
does or does not violate, infringe, or otherwise use the patents, copyrights, trademarks,
trade secrets, know-how, and/or other intellectual property of third parties, and thus any
person who implements any part of this Specification should consult an intellectual
property attorney before any such implementation. Any party seeking to implement this
Specification is solely responsible for determining whether their activities require a
license to any technology including, but not limited to, patents on public key encryption
technology. The DFS Parties shall not be liable for any party’s infringement of any
intellectual property right.
D-PAS Card Specification v1.1 Proprietary and Confidential Page 2 of 267

Effective Date: March 24, 2010 © 2009 DFS Services LLC
TABLE OF CONTENTS
1 Introduction ......................................................................................... 27
1.1 Objectives ............................................................................................................... 27
1.2 Audience................................................................................................................. 27
1.3 Scope of Document.................................................................................................. 27
1.4 New Features .......................................................................................................... 28
1.5 Document Organization ............................................................................................ 28
1.6 Data Conventions .................................................................................................... 28
1.7 Terminology ............................................................................................................ 29
1.8 Reference Documents .............................................................................................. 30
2 D-Payment Application Specification (D-PAS)...................................... 31

2.1 D-PAS Command Support ......................................................................................... 34
3 Application States................................................................................. 35
4 High-Level D-PAS Application Processing ............................................ 39

4.1 Technology Selection ............................................................................................... 41
4.2 Application Selection ................................................................................................ 41
4.2.1 Exact Match AID Selection.............................................................................. 41
4.2.2 Partial Name Selection ................................................................................... 41
4.2.3 Payment System Environment (PSE) Selection ................................................. 41
4.2.4 SELECT Response Data .................................................................................. 42
4.2.5 SELECT Response When Application Is Blocked, Card Is Blocked, or ATC Exceeded
42
4.2.6 Multi-applications – ‘AltAID’ Mechanism ........................................................... 42
4.3 Initiate Application Processing................................................................................... 43
4.4 Read Application Data .............................................................................................. 44
4.4.1 READ RECORD .............................................................................................. 44
4.4.2 GET DATA .................................................................................................... 45
4.4.3 Issuer Defined Data Tags............................................................................... 45
4.5 Offline Data Authentication ....................................................................................... 45
4.5.1 Static Data Authentication .............................................................................. 46
4.5.2 Dynamic Data Authentication.......................................................................... 46
4.6 Processing Restrictions ............................................................................................. 46
4.7 Get Challenge.......................................................................................................... 47
4.8 Cardholder Verification ............................................................................................. 47
4.9 Terminal Risk Management....................................................................................... 48
4.10 Terminal Action Analysis........................................................................................... 48
4.11 First Card Action Analysis ......................................................................................... 48
4.11.1 Velocity Checking .......................................................................................... 50
4.11.2 Previous and Current Transaction Events......................................................... 51
4.12 Second Card Action Analysis ..................................................................................... 52

4.12.1 Issuer Authentication..................................................................................... 52

4.12.2 Unable To Go Online...................................................................................... 53
4.13 Transaction Logging................................................................................................. 53
4.14 Issuer Script Command Processing ............................................................................ 54
5 Common APDU Command Processing .................................................. 57

5.1 APDU Command Components ................................................................................... 57
5.2 Common APDU Command Responses ........................................................................ 57
5.3 APDU Command Summary Table .............................................................................. 60
6 Application Commands ......................................................................... 63

6.1 Application Block...................................................................................................... 63
6.1.1 Definition and Scope...................................................................................... 63
6.1.2 Command APDU............................................................................................ 63
6.1.3 Data Field Returned in the Response Message ................................................. 64
6.1.4 Processing State Returned in the Response Message ........................................ 64
6.1.5 Transaction Flow ........................................................................................... 65
6.1.6 Notes ........................................................................................................... 66
6.1.7 Example ....................................................................................................... 66
6.2 Application Unblock.................................................................................................. 67
6.2.2 Command APDU............................................................................................ 67
6.2.6 Notes ........................................................................................................... 70
6.2.7 Example ....................................................................................................... 70
6.3 Card Block............................................................................................................... 71
6.3.2 Command APDU............................................................................................ 71
6.3.6 Notes ........................................................................................................... 74
6.4 Generate Application Cryptogram .............................................................................. 76
6.4.2 Command APDU............................................................................................ 76
6.4.6 Notes ........................................................................................................... 93
6.4.7 Example ....................................................................................................... 95
6.5 Get Challenge.......................................................................................................... 97
6.5.2 Command APDU............................................................................................ 97


6.5.4 Processing State Returned in the response Message......................................... 97
6.5.6 Notes ........................................................................................................... 98
6.5.7 Example ....................................................................................................... 99
6.6 Get Data ............................................................................................................... 100
6.6.1 Definition and Scope.................................................................................... 100
6.6.2 Command APDU.......................................................................................... 100
6.6.3 Data Field Returned in the Response Message ............................................... 101
6.6.4 Processing State Returned in the Response Message ...................................... 101
6.6.5 Transaction Flow ......................................................................................... 103
6.6.6 Notes ......................................................................................................... 104
6.6.7 Example ..................................................................................................... 105
6.7 Get Processing Options .......................................................................................... 106
6.7.2 Command APDU.......................................................................................... 106
6.7.6 Notes ......................................................................................................... 109
6.7.7 Example ..................................................................................................... 109
6.8 Internal Authenticate ............................................................................................. 111
6.8.2 Command APDU.......................................................................................... 111
6.8.6 Notes ......................................................................................................... 114
6.8.7 Example ..................................................................................................... 115
6.9 PIN Change/Unblock .............................................................................................. 116
6.9.2 Command APDU.......................................................................................... 116
6.9.6 Notes ......................................................................................................... 119
6.9.7 Example – PIN UNBLOCK ............................................................................. 119
6.9.8 Example – PIN CHANGE ............................................................................... 121
6.10 Put Data ............................................................................................................... 122
6.10.2 Command APDU.......................................................................................... 122
6.10.6 Notes ......................................................................................................... 127

6.10.7 Example ..................................................................................................... 129

6.11 Read Record.......................................................................................................... 130
6.11.2 Command APDU.......................................................................................... 130
6.11.6 Notes ......................................................................................................... 133
6.11.7 Example ..................................................................................................... 134
6.12 Select ................................................................................................................... 134
6.12.2 Command APDU.......................................................................................... 135
6.12.6 Notes ......................................................................................................... 138
6.12.7 Example ..................................................................................................... 138
6.13 Update Record ...................................................................................................... 139
6.13.2 Command APDU.......................................................................................... 139
6.13.6 Notes ......................................................................................................... 142
6.13.7 Example ..................................................................................................... 143
6.14 Verify.................................................................................................................... 144
6.14.2 Command APDU.......................................................................................... 144
6.14.6 Notes ......................................................................................................... 148
6.14.7 Example ..................................................................................................... 149
7 Issuer Script Command Processing .................................................... 151

7.1 Script Commands................................................................................................... 151
7.2 Secure Messaging Format....................................................................................... 153
7.3 Secure Messaging for Integrity (SMI)....................................................................... 153
7.4 Secure Messaging for Confidentiality ....................................................................... 154
7.5 Secure Messaging for Integrity and Confidentiality.................................................... 155
8 Security, Cryptographic Algorithms and Keys .................................... 157

8.1 Application Cryptogram Generation ......................................................................... 157
8.1.1 Data Selection............................................................................................. 157
8.1.2 Cryptogram Version Number (CVN)............................................................... 157

8.1.3 TC, ARQC and AAC Calculation ..................................................................... 158

8.1.4 ARPC Generation ......................................................................................... 159
8.2 Session Key Derivation ........................................................................................... 160
8.3 ICC Dynamic Number generation ............................................................................ 160
8.4 Symmetric Keys ..................................................................................................... 161
Appendixes
Appendix A. Acronyms & Glossary ............................................................................................. 163
Appendix B. Data Dictionary...................................................................................................... 171
1 Data Element Summary Table................................................................................. 171
2 Data Elements ....................................................................................................... 177
3 ICC Master Key Application Cryptogram (ICC MKac).................................................. 177
4 AltAIDs (Aliases).................................................................................................... 177
5 Application Cryptogram (AC)................................................................................... 177
6 Application Configuration Options (ACO) .................................................................. 178
7 Application Currency Code (9F42) ........................................................................... 179
8 Application Currency Exponent (9F44) ..................................................................... 179
9 Application Discretionary Data ................................................................................ 179
10 Application Effective Date ....................................................................................... 179
11 Application Expiration Date ..................................................................................... 179
12 Application File Locator (AFL).................................................................................. 180
13 Application Identifier (AID) ..................................................................................... 180
14 Application Interchange Profile (AIP) ....................................................................... 181
15 Application Label ................................................................................................... 182
16 Application Preferred Name .................................................................................... 182
17 Application Primary Account Number (PAN).............................................................. 182
18 Application Primary Account Number Sequence Number (PSN) .................................. 182
19 Application Priority Indicator (API)........................................................................... 182
20 Application Transaction Counter (ATC)..................................................................... 183
21 Application Usage Control (AUC) ............................................................................. 183
22 Application Version Number (AVN) .......................................................................... 184
23 Authorization Code................................................................................................. 184
24 Authorization Response Code (ARC) ........................................................................ 184
25 Card Action Codes (CACs)....................................................................................... 185
26 Card Risk Management Data Object List 1 (CDOL1) .................................................. 186
27 Card Risk Management Data Object List 2 (CDOL2) .................................................. 187
28 Card Status Update (CSU) ...................................................................................... 188
29 Card Verification Results (9F52) .............................................................................. 188
30 Cardholder Name................................................................................................... 191
31 Cardholder Name Extended .................................................................................... 191
32 Cardholder Verification Method (CVM) List ............................................................... 191
33 Certificate Authority Public Key Index (PKI).............................................................. 192
34 CRM Country Code................................................................................................. 192

35 CRM Currency Code ............................................................................................... 192

36 Cryptogram Information Data (CID) ........................................................................ 192
37 Cryptogram Version Number (CVN) ......................................................................... 193
38 Cumulative Offline Amount (COA) ........................................................................... 193
39 Currency Conversion Code 1, 2 ............................................................................... 194
40 Derivation Key Index (DKI)..................................................................................... 195
41 Dynamic Data Authentication Data Object List (DDOL) .............................................. 195
42 File Control Information (FCI) ................................................................................. 195
43 ICC Dynamic Data.................................................................................................. 195
44 ICC Dynamic Data for DDA ..................................................................................... 195
45 ICC Dynamic Number ............................................................................................. 196
46 ICC PIN Encipherment Private Key .......................................................................... 196
47 ICC PIN Encipherment Public Key Certificate ............................................................ 196
48 ICC PIN Encipherment Public Key Exponent ............................................................. 196
49 ICC PIN Encipherment Public Key Remainder ........................................................... 196
50 ICC Private Key...................................................................................................... 197
51 ICC Public Key Certificate ....................................................................................... 197
52 ICC Public Key Exponent ........................................................................................ 197
53 ICC Public Key Remainder ...................................................................................... 197
54 ICC Unpredictable Number ..................................................................................... 197
55 Issuer Action Code (IACs)....................................................................................... 197
56 Issuer Application Data (IAD).................................................................................. 199
57 Issuer Application Data Object List (IADOL) ............................................................. 200
58 Issuer Authentication Data ..................................................................................... 201
59 Issuer Code Table Index......................................................................................... 201
60 Issuer Country Code (5F28).................................................................................... 201
61 Issuer Defined Data Tags (DF01 to DF0A)............................................................... 201
62 Issuer Discretionary Data ....................................................................................... 202
63 Issuer Life Cycle Data ............................................................................................ 203
64 Issuer Public Key Certificate.................................................................................... 204
65 Issuer Public Key Exponent..................................................................................... 204
66 Issuer Public Key Remainder................................................................................... 204
67 Issuer Script Counter ............................................................................................. 204
68 Issuer Script Template 2 ........................................................................................ 204
69 Language Preference ............................................................................................. 204
70 Lower Consecutive Offline Transaction limit (LCOL) .................................................. 205
71 Lower Cumulative Offline Amount (LCOA) limit ......................................................... 205
72 Number of Consecutive Offline Transactions (NCOT)................................................. 205
73 Offline Balance ...................................................................................................... 205
74 Processing Options Data Objects List (PDOL) ........................................................... 206
75 PDOL-Check Entry ................................................................................................. 206
76 PDOL-Check Tables (Decline, Profile, Online) ........................................................... 206
77 PIN Try Counter (PTC) ........................................................................................... 206
78 PIN Try Limit ......................................................................................................... 206
79 Previous Transaction History (PTH) ......................................................................... 207

80 Profile Resource Usage Bitmap................................................................................ 209

81 Reference PIN ....................................................................................................... 209
82 SDA Tag List ......................................................................................................... 209
83 Security Counters and Limits.................................................................................. 209
84 Session Key for AC (SKAC) ....................................................................................... 211
85 Session Key for SMC (SKSMC) ................................................................................... 211
86 Session Key for SMI (SKSMI) .................................................................................... 211
87 Signed Dynamic Application Data ............................................................................ 211
88 Signed Static Application Data (SSAD) ..................................................................... 211
89 Single Transaction Amount (STA) limit..................................................................... 211
90 ICC Master Key for Secure Messaging Confidentiality (ICC MKSMC) .............................. 211
91 ICC Master Key for Secure Messaging Integrity (ICC MKSMI)....................................... 212
92 Track 2 Equivalent Data ......................................................................................... 212
93 Track 1 Discretionary Data ..................................................................................... 212
94 Transaction Log Entry ............................................................................................ 212
95 Transaction Log Format.......................................................................................... 213
96 Transaction Profile Object (TPO) ............................................................................. 213
97 Upper Consecutive Offline Transaction Limit (UCOL) ................................................. 214
98 Upper Cumulative Offline Amount Limit (UCOA)........................................................ 214
Appendix C. PDOL Processing Mechanism .................................................................................. 216
Appendix D.D-PAS Application Personalization ........................................................................... 236
Appendix E. Example Keys ........................................................................................................ 267

FIGURES
Figure 1 - STATE-MACHINE Transitions Diagram ..............................................................37
Figure 2 - D-PAS EMV Transaction Processing Flow...........................................................40
Figure 3 - Generic Command Processing Flow...................................................................59
Figure 4 - APPLICATION BLOCK Transaction Flow Diagram ...............................................65
Figure 5 - APPLICATION UNBLOCK Transaction Flow Diagram ...........................................69
Figure 6 - CARD BLOCK Transaction Flow Diagram ...........................................................73
Figure 7 - GENERATE AC Flow Diagram (Start) .................................................................80
Figure 8 - GENERATE AC Flow Diagram (AAC) ..................................................................81
Figure 9 - GENERATE AC Flow Diagram (PTH Processing) .................................................82
Figure 10 - GENERATE AC Flow Diagram (CAC) ................................................................83
Figure 11 - GENERATE AC Flow Diagram (ARQC)..............................................................84
Figure 12 - GENERATE AC Flow Diagram (CAC-Online)......................................................85
Figure 13 - GENERATE AC Flow Diagram (NCOT inc) ........................................................86
Figure 14 - GENERATE AC Flow Diagram (CRM)................................................................87
Figure 15 - GENERATE AC Flow Diagram (TC1) ................................................................88
Figure 16 - GENERATE AC Flow Diagram (Authen Data Present) ........................................89
Figure 17 - GENERATE AC Flow Diagram (No Authen Data)...............................................90
Figure 18 - GENERATE AC Flow Diagram (TC2) ................................................................91
Figure 19 - GENERATE AC Flow Diagram (GENAC) ............................................................92
Figure 20 - GET CHALLENGE Transaction Flow .................................................................98
Figure 21 - GET DATA Transaction Flow Diagram............................................................103
Figure 22 - GET PROCESSING OPTIONS Flow Diagram ...................................................108
Figure 23 - INTERNAL AUTHENTICATE Flow Diagram .....................................................113
Figure 24 - PIN CHANGE/UNBLOCK Transaction Flow Diagram. .......................................118
Figure 25 - PUT DATA Transaction Flow Diagram (part 1) ...............................................125
Figure 26 - PUT DATA Transaction Flow Diagram (part 2) ...............................................126
Figure 27 - READ RECORD Response Message Data Field................................................131
Figure 28 - READ RECORD Transaction Flow Diagram .....................................................132
Figure 29 - SELECT FILE Command Transaction Flow Diagram ........................................ 137
Figure 30 - UPDATE RECORD Transaction Flow Diagram .................................................141
Figure 31 - VERIFY Transaction Flow Diagram 1 .............................................................146
Figure 32 - VERIFY Transaction Flow Diagram 2 .............................................................147
Figure 33 - Issuer Script Commands Flow Diagram .........................................................152

Figure 34 - MAC Generation ..........................................................................................154

Figure 35 - TC, ARQC and AAC Cryptogram Generation ................................................... 159
Figure 36 - Structure of an Application File Locator (AFL) entry........................................ 180
Figure 37 - PDOL Checks Mechanism .............................................................................220
Figure 38 - PDOL Decline Check Flow Diagram ...............................................................225
Figure 39 - PDOL Profile Check Flow Diagram.................................................................226
Figure 40 - PDOL Online Check Flow Diagram.................................................................227

TABLES
Table 1 - Data Conventions .............................................................................................29
Table 2 - Reference Documents.......................................................................................30
Table 3 - D-PAS Functionality ..........................................................................................31
Table 4 - D-PAS Command Support .................................................................................34
Table 5 - Command APDU Acceptance or Rejection for Current Application State................35
Table 6 - PSE Record Format...........................................................................................42
Table 7 - Transaction Logging Configuration Options ........................................................54
Table 8 - APDU Command Summary Table.......................................................................60
Table 9 - APPLICATION BLOCK Command........................................................................63
Table 10 - APPLICATION BLOCK Status Words and Application Final State .........................64
Table 11 - APPLICATION BLOCK Command Example.........................................................66
Table 12 - APPLICATION BLOCK Response Example .........................................................67
Table 13 - APPLICATION UNBLOCK Command..................................................................67
Table 14 - APPLICATION UNBLOCK Status Words and Application Final State .....................68
Table 15 - APPLICATION UNBLOCK Command Example ....................................................70
Table 16 - APPLICATION UNBLOCK Response Example .....................................................71
Table 17 - CARD BLOCK Command ..................................................................................71
Table 18 - CARD BLOCK Status Words and Application Final State .....................................72
Table 19 - CARD BLOCK Command Example.....................................................................75
Table 20 - CARD BLOCK Response Example .....................................................................76
Table 21 - GENERATE AC Cryptogram Types ....................................................................76
Table 22 - GENERATE AC Command ................................................................................76
Table 23 - GENERATE AC Reference Control Parameter.....................................................77
Table 24 - GENERATE AC Response Data Field, CDA not requested....................................77
Table 25 - GENERATE AC Response Data Field for TC or ARQC, CDA requested..................78
Table 26 - GENERATE AC Response Message Data Field for AC, CDA requested..................78
Table 27 - GENERATE AC Cryptogram Information Data....................................................78
Table 28 - GENERATE AC Status Words and Application Final State ...................................79
Table 29 - GENERATE AC Command Example...................................................................95
Table 30 - GENERATE AC Response Example....................................................................96
Table 31 - GET CHALLENGE Command ............................................................................97
Table 32 - GET CHALLENGE Status Words and Application Final State................................97
Table 33 - GET CHALLENGE Command Example ...............................................................99

Table 34 - GET CHALLENGE Response Example................................................................99

Table 35 - GET DATA Command ....................................................................................100
Table 36 - Tags supported by the GET DATA Command ..................................................100
Table 37 - GET DATA Status Words and Application Final State .......................................101
Table 38 - GET DATA Command Example.......................................................................105
Table 39 - GET DATA Response Example .......................................................................105
Table 40 - GET PROCESSING OPTIONS Command ..........................................................106
Table 41 - Mandatory GET PROCESSING OPTIONS Response Message Data Field............. 107
Table 42 - GET PROCESSING OPTIONS Status Words and Application Final State ............. 107
Table 43 - GET PROCESSING OPTIONS Command Example ............................................109
Table 44 - GET PROCESSING OPTIONS Response Example .............................................110
Table 45 - INTERNAL AUTHENTICATE Command............................................................111
Table 46 - INTERNAL AUTHENTICATE Response Message Data Field ............................... 111
Table 47 - INTERNAL AUTHENTICATE Status Words and Application Final State ............... 112
Table 48 - Input Data to Hash Algorithm ........................................................................114
Table 49 - Data to Be Signed by ICC Private Key ............................................................115
Table 50 - INTERNAL AUTHENTICATE Command Example ..............................................115
Table 51 - INTERNAL AUTHENTICATE Format 2 Response Example................................. 115
Table 52 - PIN CHANGE/UNBLOCK Command.................................................................116
Table 53 - PIN CHANGE/UNBLOCK Status Words and Application Final State .................... 117
Table 54 - PIN UNBLOCK Command Example .................................................................119
Table 55 - PIN UNBLOCK Response Example ..................................................................120
Table 56 - PIN CHANGE Command Example ...................................................................121
Table 57 - PIN CHANGE Response Example....................................................................122
Table 58 - PUT DATA Command ....................................................................................122
Table 59 - Supported Data Objects in PUT DATA Command ............................................123
Table 60 - PUT DATA Status Words and Application Final State .......................................124
Table 61 - PUT DATA Command Example.......................................................................129
Table 62 - PUT DATA Response Example .......................................................................130
Table 63 - READ RECORD Command .............................................................................130
Table 64 - READ RECORD Command Reference Control Parameter .................................. 131
Table 65 - READ RECORD Status Words and Application Final State................................. 131
Table 66 - READ RECORD Command Example ................................................................134
Table 67 - READ RECORD Response Example.................................................................134
Table 68 - SELECT Command ........................................................................................135

Table 69 - SELECT Response Message Data Field ...........................................................135

Table 70 - SELECT Status Words and Application Final State ...........................................136
Table 71 - SELECT Command Example...........................................................................138
Table 72 - SELECT Response Example ...........................................................................138
Table 73 - UPDATE RECORD Command..........................................................................139
Table 74 - UPDATE RECORD Command Reference Control Parameter Definition ............... 139
Table 75 - UPDATE RECORD status words and application final state ............................... 140
Table 76 - UPDATE RECORD Command Example ............................................................143
Table 77 - UPDATE RECORD Response Example .............................................................144
Table 78 - VERIFY Command ........................................................................................144
Table 79 - Plaintext Offline PIN Block Format .................................................................145
Table 80 - VERIFY Status Words and Application Final State............................................145
Table 81 - VERIFY Command Example ...........................................................................149
Table 82 - VERIFY Response Example............................................................................149
Table 83 - Data to Be Included in Application Cryptogram Generation .............................. 157
Table 84 - Symmetric keys used in the D-PAS application................................................161
Table 85 - Data Elements Table.....................................................................................171
Table 86 - Application Configuration Options (ACO) Encoding ..........................................178
Table 87 - AFL Description ............................................................................................180
Table 88 - Application Interchange Profile (AIP) Encoding ...............................................181
Table 89 - Application Priority Indicator (API) Encoding...................................................182
Table 90 - Application Usage Control (AUC) Encoding .....................................................184
Table 91 - Card Action Code (CAC) Encoding ..................................................................186
Table 92 - Content of the CDOL1:..................................................................................187
Table 93 CDOL1 Content..............................................................................................187
Table 94 - CDOL2 Content.............................................................................................187
Table 95 - Card Status Update (CSU) Encoding...............................................................188
Table 96 - Card Verification Results (CVR) Encoding .......................................................189
Table 97 - Cardholder Verification Method Rule Encoding ................................................191
Table 98 - Cryptogram Information Data (CID) Encoding ................................................192
Table 99 - Currency Conversion Code Content ................................................................194
Table 100 - DDOL Content ............................................................................................195
Table 101 - ICC Dynamic Data for DDA ..........................................................................195
Table 102 - ICC Dynamic Data for CDA ..........................................................................196
Table 103 - Issuer Action Code (IAC) Encoding...............................................................198

Table 104 - Issuer Application Data (IAD) Content..........................................................200

Table 105 - Tags supported by the IADOL list.................................................................200
Table 106 - Issuer Authentication Data Content..............................................................201
Table 107 - Issuer Defined Data Tags (IDDT) Size and Access Parameters ....................... 201
Table 108 - Issuer Defined Data Tags (IDDT) Access Conditions Encoding (Byte 2) .......... 202
Table 109 - Issuer Life Cycle Data .................................................................................203
Table 110 - Previous Transaction History (PTH) Encoding................................................207
Table 111 - PTH Set and Clear conditions.......................................................................208
Table 112 - Security Counters and Limits .......................................................................209
Table 113 - Transaction Log Entry Data Element format..................................................212
Table 114 - Transaction Log Format Content ..................................................................213
Table 115 - Transaction Profile Content..........................................................................217
Table 116 - Profile Resource Usage (PRU) Encoding........................................................218
Table 117 - PDOL-Check Entry Content ..........................................................................222
Table 118 - PDOL-Check Entry, Byte 1 Encoding.............................................................223
Table 119 - PDOL-Check Entry, Byte 4 Encoding.............................................................223
Table 120 - PDOL-Check Entry, Byte 5/6 Encoding..........................................................223
Table 121 - PDOL-Check Array ......................................................................................224
Table 122 - Minimal set of Data items ............................................................................237
Table 123 - DGI Summary for Record Data ....................................................................245
Table 124 - Data Content for DGI '0101' ........................................................................246
Table 131 - Data Content for DGI '020n' ........................................................................248
Table 135 - DGI Summary for Internal Application Data ..................................................250
Table 137 - Data Content for DGI '4001' – Security limits ................................................251
Table 138 - Data Content for Templates 'BF33'-‘BF35’ ..................................................... 251

Table 139 - Data Content for Template 'BF38' Entry........................................................252

Table 140 - Data Content for Template 'BF3B' Entry ....................................................... 252
Table 141 - Data Content for Template 'BF42' Entry........................................................253
Table 142 - DGI Summary for Command Response Data.................................................253
Table 143 - Data Content for DGI ‘8000’ - 3DES keys......................................................254
Table 144 - Data Content for DGI ‘8010’ - PIN Block .......................................................254
Table 145 - Data Content for DGI ‘9010’ - PIN-related data .............................................254
Table 148 - Data Content for DDA Key data DGIs '8201' Through '8205' .......................... 255
Table 149 - Data Content for PIN Encipherment Key data DGIs '8301' Through '8305' ...... 255
Table 150 - Static Data to Be Authenticated ...................................................................256
Table 151 - INITIALISE UPDATE Command APDU...........................................................259
Table 152 - INITIALISE UPDATE Response Data.............................................................259
Table 153 - INITIALISE UPDATE Response, KEYDATA Content ........................................ 260
Table 154 - EXTERNAL AUTHENTICATE Command APDU ................................................261
Table 155 - EXTERNAL AUTHENTICATE Status Words.....................................................261
Table 156 - Security Level Encoding in Commands Following EXTERNAL AUTHENTICATE.. 262
Table 157 - STORE DATA Command APDU.....................................................................263
Table 158 - STORE DATA APDU P1 Encoding..................................................................263
Table 159 - STORE DATA APDU Response Status Words .................................................263
Table 160 - Issuer Master Keys Used in Examples...........................................................267
Table 161 - ICC Master Key Used in Examples ................................................................267

REVISION STATUS
Revision Status Date Description
1.0 Release 30 June 2009 Initial Release

1.1 Update 24 March 2009 Update. See the Summary of Changes.

SUMMARY OF CHANGES
The following table contains a summary of key changes to the D-PAS Card Specification version 1.0,
which is being updated as version 1.1.
It is important to note that this Summary of Changes is not a comprehensive list of all changes to D-
PAS Card Specification. Please carefully review this entire document for detailed changes.
Document
Section Changes
Revision Added
Summary
Section 2: D- • Table 3, D-PAS Functionality:
Payment
Application o Card Action Analysis and AC Gen: Deleted Application disabling – Mandatory
Specification (D- o Application Selection: Changed Directory Method (PSE) from an Issuer Option
PAS) to an Application Option.

Document
Section Changes
Section 2: Table 5: Command APDU Acceptance or Rejection for Current Application State –
Application modified as follows:*
States
INITIALIZED VERIFIED CHALLENGED SCRIPT
GET A A A R
CHALLENGE
GET DATA A A A A
GET DATA A A A A
(GPO
PROTECTED)
INTERNAL A A A R
AUTHENTICATE
VERIFY A A A R
[Plaintext]
VERIFY R R A R
[Encrypted]
*Note:
Modified the Application Protocol Data Unit (APDU) Acceptance (A) and Rejection
(R) responses for the following commands to meet current terminal requirements:
• CHALLENGED State - GET CHALLENGE: Changed the response to
“A”.
• SCRIPT State - GET DATA, GET DATA (GPO PROTECTED), GET DATA
(PIN PROTECTED), and READ RECORD commands: Changed the
response to “A”.
• INITIALIZED and VERIFIED State - INTERNAL AUTHENTICATE
command: Changed the response to “A”.
• VERIFY command: Split into two components - plaintext and
encrypted to enable the use of separate A and R criteria.
Section 4: High- • Section 4.11.1 Velocity Checking (Paragraph 4):
Level D-PAS
Application o Added unless bit 3 of the PRU byte for ‘Profile 0’ is set as follows:
Processing “If transaction profiles are not defined by the issuer, the NCOT in the ‘default
profile’ shall be used for all transactions, unless bit 3 of the PRU byte for
‘Profile 0’ is set.”
• Section 4.12.1 Issuer Authentication:
o Added clarifying information regarding the use of counters and the

processing of Issuer Authentication Data for Partial Transactions.

Document
Section Changes
Section 5: • Section 5.2 Common APDU Command Responses:
Common APDU
Command o At the end of the section, added a note that designates the sequence of the
Processing figures in the following sections as “recommended” rather than
“mandatory”.
• Section 5.3 APDU Command Summary Table (Table 10):
o Included the VERIFY command to correct an omission.

Section 6: • Multiple tables: Updated to address typographical errors related to the ’69 82’,
Application ’69 88’, and ‘6A 88’ tags.
Commands
• Sections 6.1.6, 6.2.6, 6.3.6, 6.9.6, 6.10.6, 6.13.6 figure note – Added the
following information regarding the ‘Script Failed’ bit:
o “The ‘Script Failed’ bit in PTH (B1b1) is set by default, and only
cleared when the command is successful. Any error condition
should thus result in a ‘Script Failed’ bit of PTH being set.”
• Section 6.4.3 Data Field Returned in the Response Message:
o Updated the section and Tables 25 and 26 to address Combined Dynamic

Data Authentication Application Cryptogram (CDA) requests.
• Figures 12, 13, and 15 – GENERATE AC Flow Diagrams: Modified to include the
Number of Consecutive Offline Transactions (NCOT).
• Figures 10 through 17 - GENERATE AC Flow Diagrams: Updated the order of the

figures to reflect the recommended processing sequence.
• Section 6.4.6 S11 and S12: Expanded to include additional details regarding the
setting of Profile Resource Usage (PRU) values versus the acceptance of default
global values.
• Section 6.5.1 and 6.5.5 (Figure 20): Modified the description of the GET
CHALLENGE command to include the availability of the command in the
VERIFIED state.
• Section 6.6.2 (Table 36): Typographical Error and Omission:
o Replaced Card Application Life Cycle Data with the Issuer Life Cycle Data
(global change).
o Added CRM Country Code to the table.
• Section 6.6.6 (S2): Expanded to include the Counter Value/Limit and the
associated data elements to be checked for an Offline Balance Data Object
or a Counter Value/Limit.
• Figure 21:
o Added cross reference between GPO command execution and profile specific
tag read access request.
o Added flow for Issuer Defined Data Tags (IDDT).
o Added edit for handling overflow of offline balance.

Document
Section Changes
• Section 6.9.2 Command APDU:
o Last paragraph - Changed the PIN data to be used in the MAC generation
from its plaintext value to an “encrypted PIN block”.
• Section 6.9.4 Processing State Returned in Response Message:
o Table 53 – Modified by replacing the values associated with the SELECTED

state with decrypted and secure messaging values.
• Section 6.10.2, Table 59 – Updated to emphasize the need to set the designated
data elements rather than accept default (global) values and added CRMs as
follows:
o Changed the term profile-specific to profile-specified.

o Added a note further defining differences between profile-specific and global
CRM resources.
o Added CRM Country Codes to the table.
• 6.12.3 (Table 69):
o Changed the FCI Proprietary Template for the Application Label to

Mandatory “M” to reflect current EMV terminal practices.
o Changed the Issuer Country Code Tag from ‘5F56’ to ‘5F28’.
• 6.12.4 (Table 70): Expanded the table note to include “and error codes” to
address an omission.
• 6.13.2 (Table 73): Added “command” to the value of the Lc to read as “Length
of command data” to address an omission.
• 6.13.7: Modified the Parameters, Details, and Lc of Table 76 to

address current terminal requirements for the UPDATE RECORD
command.
• Section 6.14.2 Command APDU (paragraph 3):
o Clarified that the Command Data Length (Lc) varies based on whether the
PIN block is enciphered or plaintext.
• Section 6.14.4 Processing State Returned in the Response Message (Table 82):
o Added the ’67 00’ SW1 SW2 error code to the table.
• Section 6.14.6 Notes (S4):
o Expanded to include the Application Configuration Option (ACO) as follows:

“If an ICC PIN Encipherment Key is present and the ACO Byte 1 bit 7 is
configured, it is selected. If not present, the ICC Key is selected for use in
the subsequent steps.
Section 7 Issuer • Section 7.3 Secure Messaging for Integrity (SMI):
Script Command
Processing o Added an example to List item 1, bullet 3 as a means of clarifying the
processing of the unpredictable value R.

Document
Section Changes
Appendix B • Table 85 – Data Elements Table: Updated the following data elements:
o Alternate Application Identifier (added)

o Application Discretionary data (updated and changed the tag from 9F0F to
9F05.
o Card Application Life Cycle Data (deleted)
o Issuer Life Cycle Data (added)
o Issuer Script Counter (changed from Issuer Script Command Counter
o Service Code (added)
• Table 86 - Application Configuration Options (ACO) Encoding:
o B1b5: Deleted Issuer Authentication is Mandatory and inserted “Partial Chip

Implementation authorization response accepted” [to enable Partial
Chip authorizations].
o B1b4: Deleted Issuer Authentication required to pass to reset Velocity
indicators and counters (COA, NCOT profile-specific) and inserted “Reset
Offline counters during Partial Chip Implementation transaction”.
o B2b 7: Deleted Issuer Authentication Data and inserted “Include only CVR
in input data for Application Cryptogram”.
o B2b3: Changed value from 1 to 0 and deleted Reserve global NCOT counter
for transactions in which currency is not recognized. Replaced with: RFU
[Reserved for Future Use].
o Added a note applicable to B2b7 to the table.
• Table 93 - Card Action Code (CAC) Encoding:
o B2b8: Replaced Off-line PIN verification not performed with Invalid PDOL
check.
o B2b4, B2b3, B2b2, B2b1 - Added “Note: May be profile-specific”
o Inserted after the table for clarification: “Note: Bits shaded in Blue are not
significant in the CAC-denial array.”
• Section 25 - Deleted:
D-PAS application proprietary data element that provides traceability of the D-PAS
chip card and its personalization.
It shall contain at a minimum:
• IC Type
• IC Serial Number
• IC Personalization Date
The Card Application Life Cycle Data is stored at the card level and may be obtained
using the GET DATA command.
Format: Binary, variable length.
• Section 27 – Added for clarification: “Note: If Issuer Authentication Data is

not received, the application uses 10 bytes of '00' to represent issuer
authentication data in CDOL2.”

Document
Section Changes
• Table 95 - Card Status Update (CSU) Encoding:
o B2b6 – Omission error: Added “1” and “DO NOT Reset Script Counter”
o B2b4 - Added for clarification: “If the PTC value in CSU B1b4-b1 > PTL
then PTC is updated with PTL value.”
• Table 96 - Card Verification Results (CVR) Encoding updated as follows:
o B2b2 - Typographical error: Replaced “0” | “RFU” with ‘1” | “CAC-default

ignored with CAT3 terminal”
o B2b1 – Omission error: Added “0” and “RFU”
o B5b8: Replaced Off-line PIN verification not performed with “Invalid PDOL
check.”
o B5b4, B5b3, B5b2, B5b1 - Added “Note: May be profile-specific.”
• Section 39 Currency Conversion Code 1, 2: Addressed typographical errors in the
Example conversion.
• Format – bytes: Modified the formats in the following sections to meet current
terminal requirements: Sections 41, 69, 70, 71, 72, 88, 95, 96, and 97.
• Section 56 - Issuer Application Data Object List (IADOL): Modified the section
and Table 105 to clarify the use of IADOL.
• Section 57 - Issuer Application Data Object List (IADOL): Included CVM

Results in Table 105.
• Section 60 - Issuer Defined Data Tags (DF01 to DF0A): Added a note to show
the maximum size of Issuer Defined Data Tags.
• Table 108 – Issuer Defined Data Tags (IDDT) Access Conditions Encoding B2b3:
Replaced “1” with “0”.
• Section 62 Issuer Life Cycle Data: New section added to address Issuer Life
Cycle Data.
• Section 66 - Issuer Script Counter: Expanded the section to include detail

regarding a reset after a successful online transaction.
• Section 74 - PDOL-Check Entry: Expanded the section.
• Section 78 - Previous Transaction History (PTH)
o Table 110 - B1b5: Added a note to address the option of sending the first
transaction of a new card online.
o Table 111 – Added a new table to provide the conditions for setting and
clearing the contents of the PTH.
• Section 80 Reference PIN: Added a new section to describe the functionality of
the Reference PIN, which is a D-PAS proprietary data element.

Document
Section Changes
• Section 82 Security Counters and Limits (Table 113): Included information in
the Purpose column relative to exceeding the: ATC Limit, Encrypted PIN
cryptography failure limit, Failed MAC limit, Lifetime MAC Limit, Script Counter,
and Session MAC Limit.
• Section 93 Transaction Log Entry: Added a note and modified Table 114 BYTE 1
to verify the location of the Short File Identifier (SFI).
Appendix C • Section 1 Transaction Profiles: Added “PRU” to the first table and modified the
number of bytes to match the current values included in Appendix B for the
NCOT counter and LCOL, UCOL, LCOA, UCOA, and STA limits.
• Table 117 – Transaction Profile Content: Added the following to the designated
bits for clarification:
o bit2: (Note: when bit value = 0, use global NCOT counter)

o bit1: NCOT usage for unrecognized currencies
If b1=1 then NCOT counts only offline transactions in which
currency is not recognized.
Else:
If b1 = 0, profile-specific (or global) NCOT counts all offline
transactions, regardless of currency code.
• Table 117, Note, paragraph 3: Clarified that the selection of a particular profile
will overwrite the Card Risk Management (CRM) resources specified in the global
profile as follows:
“These elements may also be individually accessed using the ‘Get Data’
command and tags in the range ‘C5’-‘CD’. A ‘Put Data’ command referencing
one of these data items directly (tags ‘C5’-‘CC’) will affect the CRM resource
specified in the current profile (as specified in the PRU bitmap). If the
resource being used by the currently selected profile is defined as being
‘Global’ (relevant PRU bit set to ‘0’), the data item in ‘profile 0’ will be
modified.”
• Table 118 – PDOL – Check Entry Content. Changes the Bit Mask for the Ref Data
Size by changing the value from 1 to 0 as follows: “(set bits you wish to
ignore to 0)”
• Table 119 – PDOL Check Entry Content: Modified the B1b8 encoding to include
values for both contact and contactless options as follows:
“Interface type (b8 = 0: contact interface, b8 = 1:contactless)”

Document
Section Changes
• Section 2, Table 122: Modified the following Tags and Total Length of the PDOL-
Check Arrays to reflect currently used terminal values:
Tag - Length ‘DF10’ ‘xx’ (xx = total length of PDOL-Decline array)

Tag - Length ‘DF11’ ‘yy’ (yy = total length of PDOL-Profile array)
Tag-Length ‘DF12’ ‘zz’ (zz = total length of PDOL-Online array)
• Section 2 PDOL Check Mechanism (Implementation Example): Modified the

example to include the updated PDOL Tag Lengths noted in Table 122 and Bit
Mask noted in Table 118.
Appendix D, D- • Section 1, Table 123. Modified the Length to conform to standard terminal
PAS Application practices for the following Data Elements:
Personalization
Tag Data Element Length CPS

Location
DGI
‘CB’ LCOL (Lower 1 ‘BF3D’
Default ‘Profile 0’
Consecutive Offline
resources
Limit)
‘CC’ UCOL (Upper 1 ‘BF3D’
Consecutive Offline
resources
Limit)
‘C8’ LCOA (Lower 6 ‘BF3D’
Cumulative Offline
resources
Amount) limit
‘C9’ UCOA (Upper 6 ‘BF3D’
Cumulative Offline
resources
Amount) limit
‘CA’ STA (Single Transaction Default ‘Profile 0’ 6 ‘BF3D’
Amount) limit resources
• Section 3.1.5 Store Data Command: Modified as follows to add a restriction to
the STORE DATA command header based on current practice:
o “The P1 value in the STORE DATA command header shall be ignored except
for the 3 first high-order bits, used to indicate an encrypted DGI or the
last STORE DATA command.”
• Section 3.8, Table 132 – Data Content for DCI ‘020n’: Modified to enable
conformity between this Card Specification and the D-PAS Key Management
Guide.
• Table 137 - Data Content for DGI '4000': Changed the Length for the ‘C2’ Data
Element to 48 based on current practices.

Document
Section Changes
• Table 141 – Data Content for Template ‘BF3b’ Entry:
o Modified the following values to reflect current practices:

Data Element Length
NCOT (Number of Consecutive 1

Offline Transactions) counter
LCOL (Lower Consecutive Offline 1

Limit)
UCOL (Upper Consecutive Offline 1

Limit)
LCOA (Lower Cumulative Offline 6

Amount) limit
UCOA (Upper Cumulative Offline 6

Amount) limit
STA (Single Transaction Amount) 6

limit
• Section 5.3 Store Data Command: Added reference to [EMV CPS] to clarify
encryption/decryption requirements.
Appendix E, • Table 161 – Issuer Master Keys Used in Examples and Table 162 – ICC Master
Example Keys Key Used in Examples: Inserted additional information for the Ac Gen, Script
MAC, and Script Encrypt for the master keys used in examples.

1 INTRODUCTION
This document describes the technical and functional specifications of the D-Payment
Application Specification (D-PAS) chip card application, which is compliant with EMV™ v4.2
specifications.1 These specifications are meant to be generic, in that the D-PAS application
may be implemented on many different card types by multiple application providers.
1.1 OBJECTIVES
The objective of this document is to provide guidance information for the implementation of
the D-PAS application. It is meant to be a stand-alone specification which provides all of the
technical information necessary to create a D-PAS-compliant application.
1.2 AUDIENCE
The target audience for this document is developers of the D-PAS application, as well as
system integrators working with issuers and employees of Discover Financial Services (DFS).
The guide may also be useful for issuers and Card Bureaus involved in the personalization of
the D-PAS application.
1.3 SCOPE OF DOCUMENT

This document includes all technical data required for elaboration of the D-PAS application.
The actual binary content of APDU commands and possible response codes are provided
herein, as well as a list of all tags for internal card data elements, and flow-charts illustrating
the required processing flow.
A detailed ‘reference implementation’ of certain functionalities is included in some sections of

this document, but in some cases this is only done to clarify functional requirements, and
provide guidance for application developers. These examples are not meant to be restrictive,
in that other methods of meeting the same functional requirements may also be considered.
1
EMV™ is a trademark owned by EMVCo LLC.

1.4 NEW FEATURES

A number of optional new and innovative features have been built into the D-PAS application.
These features include:
• The ability for the issuer to create 3 or more Alternate AIDs (AltAIDs), or
Aliases for the D-PAS application. Each ‘AltAID’ shall have its own File Control
Information (FCI) and Processing Data Objects List (PDOL) list, and shall allow
the D-PAS application to be selected according to multiple Application Identifiers
(AIDs) for regional specifics.
• The ability to create 3 or more ‘Transaction profiles’, which contain a profile-

specific Application Interchange Profile (AIP), Application File Locator (AFL),
Offline limits and counter, and profile-specific set of Card Risk Management
(CRM) Card Action Codes (CACs). Profile selection shall take place during the
initial ‘GPO’ command.
• Enhanced CRM functionalities, including PDOL-based GET PROCESSING

OPTIONS (GPO) ‘pre-processing’, during which additional card risk management
checks may be performed. GPO pre-processing may cause a transaction to be
declined, may force a transaction Online, and/or may provide the option to
select a specific ‘Transaction profile’ with which to perform the EMV transaction.
• Customizable Issuer Application Data provided through the use of an Issuer

Application Data Object List (IADOL) list of data elements that shall be returned
in Issuer Application Data (IAD). Based on contents of the IADOL list, the card
shall populate the IAD with the proper elements in the specified sequence.
• Flexible file structure, supporting (optional) predefined ‘User-specific’ tagged

elements which may be configured by the issuer as well as the standard EMV
tags and ‘Record’ files. Data access conditions are configurable; Issuer Defined
Data Tag (IDDT) data access may require a prior Personal Identification
Number (PIN) presentation to Read, and Secure Messaging to update. Read
access to Terminal File Records may also be configured so that a successful
GPO command is mandatory before the first ‘Read Record’ or ‘Get Data’
command is received.
• New Cryptographic options include use of the EMV Common Session Key (CSK)
derivation mechanism, and Common Core Definitions (CCD)-compliant
Application Cryptograms.
These configuration and implementation options are detailed in the following sections.
1.5 DOCUMENT ORGANIZATION

This specification is organized using the data conventions and section structure described in the following
subsections. A combined list of acronyms and glossary is included as Appendix A.
1.6 DATA CONVENTIONS

The data conventions included in the following table are used in this document.

Table 1 - Data Conventions

Convention Description
“…” Double quotation marks surround names or actual values
‘…’ Single quotation marks surround a hexadecimal number.

For example ‘3A’ or ‘9901’
[…] Squared brackets surround a reference document.
For example [EMV 4.2]
|| The concatenation of two array of bytes
Y = DES(K)[D], Y is the result of using a Data Encryption Standard (DES) to
encrypt an 8-byte data block D with key 8-byte key K
Y = DES-1(K)[D], Y is the result of using DES to decrypt an 8-byte data block D
with key 8-byte key K
Y = DES3(K)[D], Y = DES(KL)[DES-1(KR)[DES(KL)[D]]]
where
D is an 8 byte data block
K is a 16-byte key and K = KL || KR
KL is the leftmost 8 bytes of K
KR is the rightmost 8 bytes of K
Y = DES3-1(K)[D], Y = DES-1(KL)[DES(KR)[DES-1(KL)[D]]]
where
D is an 8 byte data block
K is a 16-byte key and K = KL || KR
KL is the leftmost 8 bytes of K
KR is the rightmost 8 bytes of K
Bit map Within a byte, bit 8 (b8) is the most significant (& leftmost) bit.
Bit 1 (b1) is the least significant (rightmost) bit.
Bxby Bit identifier in a multi-byte data object
‘B’ identifies a Byte
‘b’ identifies a bit
E.g. Byte 1 bit 2 is represented as B1b2
1.7 TERMINOLOGY
The following terminology applies:
• “shall”, “ must”, “required” - Denotes a mandatory requirement
• “should” - Denotes a recommendation
• “may”, “optional” - Denotes an optional feature

1.8 REFERENCE DOCUMENTS

The documents listed in Table 2 are notated within this specification using the abbreviations
provided. In some cases, additional details on specific document sections are included within
a particular reference notation for increased ease of use.
Prior to acquiring and using any one of these Reference Documents to obtain additional
information, please check for any updates in the D-PAS bulletin section of Infonet.
Table 2 - Reference Documents
Title Source Reference
D-PAS Terminal Specification, Version 1.0, June 2009 1 [D-PAS TS]

EMV. Integrated Circuit Card Specifications for Payment 2 [EMV 4.2-1]
Systems. Book 1 - Application Independent ICC to Terminal
Interface Requirements, Version 4.2. June 2008
Systems. Book 2 - Security and Key Management, Version 4.2.
June 2008
Systems. Book 3 - Application Specification, Version 4.2. June
2008
Systems. Book 4 - Cardholder, Attendant, and Acquirer
Interface Requirements, Version 4.2 dated June 2008
Draft Specification Update Bulletin No. 74, First Edition 2 [EMV AES]
November 2008
EMVCo. Issuer and Application Security Guidelines. Version 2 [EMV IASG]
2.1. November 2007
Notice Bulletin No. 12: Annual RSA Key Length Assessment. 2 [EMV RKLA]
October 2008
Common Payment Application Specifications v1.0 Dec 2005 + 2 [EMV CPA]
Update bulletins
EMV Card Personalization Specification, version 1.1, June 2007 2 [EMV CPS]
ISO 639-1: Codes for the representation of names of 4 [ISO-639-1]

languages - Part 1: Alpha 2 code
ISO/IEC 7816-4 Identification cards — Integrated circuit cards 3 [ISO7816-4]

— Part 4: Organization, security and commands for
interchange
1 = Available from Discover Financial Services.

2 = Available from the EMVCo web site (www.emvco.com)
3 = Available from International Organization for Standardization

2 D-PAYMENT APPLICATION SPECIFICATION (D-PAS)

The D-PAS application specifications describe a number of functionalities. A specific
functionality described in D-PAS is classified as:
• Mandatory: This must be present and must conform to the behavior described
in the D-PAS application specifications.
• Issuer Option: This must be present in the D-PAS application but the issuer
may configure the application to not use the feature.
• Application Option: Presence or absence of these functionalities is a choice of

the application developer.
• Not Supported: These functionalities are not supported in the specification.
• No Card Impact: This is supported by the Card and/or Terminal Specification,

but has no impact on the D-PAS application.
Table 3 - D-PAS Functionality
Function D-PAS Support Notes
Offline balance support in Answer To Reset (ATR) Issuer Option

Application Selection Mandatory
• Explicit Selection • Mandatory
• Directory Method (PSE) • Application Option
• Partial Name • Mandatory
• Alt AID • Issuer Option
• Use of PDOL • Issuer Option
Initiate Application Mandatory
• AIP indicators • Mandatory
• PDOL Decline • Application Option
• PDOL Online • Application Option
• Multiple Transaction Profiles • Issuer Option A default Transaction
Profile is mandatory;
multiple profiles are
optional.
Read Application Data Mandatory
• EMV Data in Terminal File records, identified • Mandatory
by Short File Identifier (SFI) and record
number.
• Profile specific files • Mandatory
• Issuer Defined Tags • Application Option
• GPO for Tagged Data • Application Option
• Access to Offline Counters & Balance • Issuer Option

Offline Data Authentication Optional

• Static Data Authentication (SDA) • No Card Impact Value must be
personalized in the card,
unless card is “online-
only”.
• Dynamic Data Authentication (DDA) • Application Option Requires chip Rivest,
Shamir & Adleman (RSA)
co-processor
• Combined DDA/Application Cryptogram • Application Option Requires chip RSA co-
Generation (CDA) processor
Processing Restrictions Mandatory
• App Version Number • Mandatory
• App Usage Control • Mandatory No card impact, but
appropriate values must
• Effective Date • Mandatory
be personalized.
• Expiration Date • Mandatory
Cardholder Verification Mandatory
• Signature • No Card Impact Value must be
personalized, if used.
• Online PIN • No Card Impact Value must be

personalized for Cash
transactions.
• Offline Plaintext PIN • Issuer Option

• PIN & Signature • Issuer Option
• Offline Encrypted PIN • Application Option
• with different RSA Keys • Issuer Option
• NO Cardholder Verification Method (CVM) • No Card Impact Value must be
personalized, if used.
Terminal Risk Management Mandatory
• Velocity Check • Not Supported
• Floor Limit • No Card Impact
• Exception File • No Card Impact
• Random Selection • No Card Impact
• Merchant Forced Online • No Card Impact

Card Action Analysis and AC Gen Mandatory

• Blocked Application • Issuer Option
• CRM – Cum. Number • Mandatory
• CRM – Cum. Amount • Mandatory
• CRM – Single Amount • Issuer Option
• PIN Try Limit • Mandatory
• Unable to go Online • Mandatory
• Previous Transaction • Mandatory
• PDOL CRM • Issuer Option
• Offline Referral • Not Supported
• Advices • Not Supported
• Decision- Online/Offline • Mandatory
• Cryptogram • Mandatory
• Data Encryption Standard (DES) Algorithm • Mandatory
• Advanced Encryption Standard (AES) • Not Supported
Algorithm
• Issuer Option
• IADOL
• Issuer Option
• Counters in Cryptogram
• Mandatory
• Transaction Log
Online Mandatory
• Issuer Authentication • Issuer Option
• Reset Counters after Issuer Authentication • Issuer Option
Script Processing Mandatory
• Secure Messaging • Mandatory
• Application Block/Unblock • Issuer Option
• PIN Change/Unblock • Issuer Option
• Card Block • Application Option Use of Card Block is an
Issuer option if supported
• Put Data • Issuer Option
by the card platform.
• Update Record • Issuer Option
Completion Mandatory
Personalization – CPS Application Option

2.1 D-PAS COMMAND SUPPORT

This Application Specification describes a number of Application Protocol Data Unit (APDU)
commands. A specific command described in the application specification is classified as:
• Mandatory: This must be supported in the D-PAS application.
• Optional: Presence or absence of these commands is a choice of the D-PAS

application developer.
• Conditional: Presence or absence of these functionalities is dependant on the

corresponding functionality being available in the D-PAS application.
• Not supported: These functionalities are not supported in the specification.
Table 4 - D-PAS Command Support
Command D-PAS Support
APPLICATION BLOCK Mandatory

APPLICATION UNBLOCK Mandatory
CARD BLOCK Optional
EXTERNAL AUTHENTICATE Not Supported
EXTERNAL AUTHENTICATE (CPS) Conditional
Mandatory if CPS is supported
GENERATE Application Cryptogram (AC) Mandatory
GET CHALLENGE Conditional –
Mandatory if Offline Enciphered PIN is supported
GET DATA Mandatory
GET PROCESSING OPTIONS Mandatory
GET RESPONSE Mandatory for T=0 cards
INITIALIZE UPDATE Conditional
INTERNAL AUTHENTICATE Conditional
Mandatory if DDA is supported
PIN CHANGE/UNBLOCK Conditional
Mandatory if Offline PIN is supported
PUT DATA Mandatory
READ RECORD Mandatory
SELECT Mandatory
STORE DATA Conditional
UPDATE RECORD Mandatory
VERIFY Conditional
Mandatory if Offline PIN is supported

3 APPLICATION STATES
The D-PAS application is built on a state machine architecture, which controls the availability
of certain APDU commands. The D-PAS application is free to implement the state machine in
any way it sees fit, but the application must be able to record the following four main
application states and two sub-states:
• SELECTED: The D-PAS application has been selected using the ISO-standard
‘Select DF’ command.
• INITIALIZED: The D-PAS application has successfully processed the GPO APDU
command.
• ONLINE: The D-PAS application has returned an Authorization Request

Cryptogram (ARQC) in response to the 1st ‘Generate AC’ (GEN AC) APDU
command.
• SCRIPT: The D-PAS application has returned a Transaction Certificate (TC) or

an Application Authentication Cryptogram (AAC) in response to a 1st or 2nd
‘Generate AC’ APDU command.
• (sub) VERIFIED: The D-PAS application has received a correct ‘Verify PIN’ APDU
command.
• (sub) CHALLENGED: The D-PAS application has successfully processed a ‘Get

Challenge’ APDU command.
The D-PAS application shall accept or reject a command APDU, according to its current state
and the following table.
Table 5 - Command APDU Acceptance or Rejection for Current Application State
SELECTED INITIALIZED VERIFIED CHALLENGED ONLINE SCRIPT
APPLICATION R R R R R A
BLOCK
APPLICATION R R R R R A
UNBLOCK
CARD BLOCK R R R R R A
GENERATE R A A A A R
APPLICATION
CRYPTOGRAM
GET R A A A R R
CHALLENGE
GET DATA A A A A R A
GET DATA (GPO R A A A R A

PROTECTED)
GET DATA (PIN R R A A R A

PROTECTED)
GET A R R R R R

SELECTED INITIALIZED VERIFIED CHALLENGED ONLINE SCRIPT
PROCESSING
OPTIONS
INTERNAL R A A A R R
AUTHENTICATE
PIN R R R R R A
CHANGE/UNBLO
CK
PUT DATA R R R R R A
READ RECORD A A A A R A
READ RECORD R A A A R R
(GPO
PROTECTED)
SELECT A A A A A A
UPDATE R R R R R A
RECORD
VERIFY A A A A R R
[Plaintext]
VERIFY R R R A R R
[Encrypted]
A = APDU accepted.
R = APDU rejected.

Application State transitions are illustrated in the following diagram.
Figure 1 - STATE-MACHINE Transitions Diagram
IDLE Unprotected
SELECT DF IDDT PUT DATA
Unprotected
DE-SELECT or RESET GET DATA
+ READ RECORD
SELECTED
VERIFY PIN
[Plaintext]
GPO-protected
GET DATA Scripted
INTERNAL + READ RECORD command fails
VERIFIED AUTHENTICATE GPO
GET
INITIALIZED
CHALLENGE
VERIFY PIN
[Plaintext] Any other CHALLENGED
1st GEN AC
command
PIN Protected
GET Data IDDT
VERIFY PIN
[Enciphered]
ARQC in 1st
GEN AC
TC or AAC in 1st GEN AC
PIN Protected, Unprotected, or
GPO protected PUT Data IDDT GET
(no Secure Messaging) CHALLENGE
GET DATA (all)

+ READ RECORD
TC or AAC in
2nd GEN AC
2nd GEN AC
ONLINE
SCRIPT
All Scripted commands
(Secure Messaging)
VERIFIED
LEGEND: PIN Protected

PUT Data IDDT
(with Secure Messaging)
Command failed
Command succeeded
Command failed
or succeeded

[This page is intentionally left blank.]

4 HIGH-LEVEL D-PAS APPLICATION PROCESSING

This section provides a high-level description of the D-PAS application transaction processing
flow. Additional details on each APDU command mentioned in this chapter are provided in
following sections of this document.
The D-PAS application follows a standard EMV transaction processing flow, as described in
[EMV 4.2-2]. Additional internal card processes have been added to provide a maximum
amount of flexibility to the D-PAS application (e.g., PDOL pre-processing and Transaction
profile selection, or IADOL-configurable IAD contents).
The following diagram provides a general overview of the standard D-PAS transaction process
flow for both the terminal and card specification. For information regarding the steps
associated with the D-PAS Terminal, refer to the [D-PAS TS] document.

Figure 2 - D-PAS EMV Transaction Processing Flow
D-PAS Chip Card Chip Card Terminal

Pr e- Chip Card Insertio n/ Terminal powers up chip card and establishes
Tra ns a c tion Chip card is inserted
An swe r to Rese t communic atio n
Proc e s s ing
Step 1: Application
Chip card provid es supported appli cations Terminal di entifies and sele cts an applic atio n
Selection
Chip card provid es appli cation capabili ties
Step 2: Initiate and locatio n of data
Terminal initiates transaction
Applicatio n Processing
Step 3: Read Applicat oi n Chip car d provides application data Terminal requests and stores application data
Data
Step 4: Offline Da ta
Authe ntication fI DD A: chip card generates security data IfSD A orD DA: terminal vali date s chip card
Step 5: Processing Terminal identifie s transaction restrictio ns

Restr ictions
Termin al valid ates cardhold er

Step 6: Cardh older
Ver fi ci a tion If offli ne PIN: chip card provid es PIN -
If offli ne P IN : te rminal sends PIN to chip card
related details and vali dation
Step 7: Te rmina lRisk If requested: chip card provides ris k

Termin al performs a series ofrisk checks
M anage ment management counters
Step 8: Fir st Ter minal Action Termin al recommends the transaction be

declin ed, sent onli ne or approved
Analysis
Tr a ns ac tion
Ex e c ution Chip card determines fi the rt ansaction is
declined, sent online or approved
Step 9: Fir st Card Action
Analysis fI CD A: chip card generates security data
If CDA: termin al valid ates chip card
Step 10: Online Pr ocessing

Terminal executes authorization
Step 11: Second Ter minal Termin al recommends the transaction be

Action Ana yl sis declined or approved
If appro ved or declined
C hip card determin es if the transaction is to

Step 12: Second Ca rd Action be declined or approved
Analysis
fI CD A: chip card generates security data
If CDA: termin al valid ates chip card

Step 13: Transactio n
Com pletion
Termin al executes approval or declin e
Step 14: Issue r to Car d

Chip card processes scripts If present: te rminal sends scripts to chip card
Script Pr ocessing
Po st - Con clu sion of Pro cessing/
Tra ns a c tion Chip Ca rd Deact vi a tion and Terminal pr in ts receip t and deactiv ates chip
Proc e s s ing card
Rem oval

4.1 TECHNOLOGY SELECTION

If the service code in the card magnetic stripe indicates the card has Integrated Circuit Card
(ICC) capability and the terminal has been certified for D-PAS and has the D-PAS AIDs
loaded, then the terminal must complete the payment transaction using the D-PAS
application. However, it may be possible under certain conditions to ‘fall-back’ to a magnetic-
stripe transaction. The conditions under which a transaction may fall-back to magnetic stripe
technology are defined by business requirements for the terminal application and are out of
the scope of this D-PAS application specification. The card shall be equipped with an
appropriately coded magnetic stripe containing Track 1 and/or Track 2 data, to permit such a
fallback.
The first digit of the service code for a D-PAS chip card must be:
“6” for domestic cards
“2” for international cards
On some card platforms, the discretionary part of ATR data may be updated by the D-PAS
application. For example, this may be used by the issuer to display an offline balance.
4.2 APPLICATION SELECTION

The D-PAS application shall support selection of the application using the SELECT command
as described in [EMV 4.2-1] and [EMV 4.2-3].
4.2.1 EXACT MATCH AID SELECTION

It shall be possible to select the D-PAS application using ‘exact match’ AID selection.
4.2.2 PARTIAL NAME SELECTION

It shall be possible to select the D-PAS application using partial name selection.
4.2.3 PAYMENT SYSTEM ENVIRONMENT (PSE) SELECTION

The presence of the PSE (as described in [EMV 4.2-1]) on the ICC is optional. If the PSE is
instantiated in the D-PAS application, the PSE entry for each registered payment application
must have the following format.

Table 6 - PSE Record Format

Tag-
Length Value Presence
‘70xx’ Template (xx denotes length of following bytes) M
‘61xx’ Application Template M
‘4Fxx’ ‘A000000152’ || PIX M
‘50xx’ Alphanumeric encoded name of application M

e.g., “D-Chip App”
‘8701’ Priority Indicator M
Tag || ‘xx’ Other optional Data Objects allowed in EMV O
Key: M=Mandatory
O=Optional
The EMV implicit selection mechanism using PSE is outside the scope of the D-PAS application
specification.
4.2.4 SELECT RESPONSE DATA

The FCI data returned by the D-PAS application in response to a SELECT command shall be an
issuer option.
If the ‘PDOL check’ mechanism described in Appendix C is being used, then the FCI may
contain a PDOL list, specifying the tagged ‘terminal-resident’ data objects the card expects to
receive in the GET PROCESSING OPTIONS APDU command.
4.2.5 SELECT RESPONSE WHEN APPLICATION IS BLOCKED, CARD IS BLOCKED,

OR ATC EXCEEDED
If the D-PAS application has been blocked by a previous APPLICATION BLOCK command, the
status words SW1 SW2 returned in response to the SELECT command shall be ‘6283’
(Selected file invalidated).
Any terminal intended to be used to unblock the application shall continue to proceed with the
transaction in order to unblock that application with that AID.
If the D-PAS chip card has been blocked by a previous CARD BLOCK command, the status
words SW1 SW2 returned in response to the SELECT command shall be ‘6A81’ (Function not
supported).
If the ATC Limit of the D-PAS application is exceeded, the status words SW1 SW2 returned in
response to the SELECT command shall be '6985' (Conditions of use not satisfied).
4.2.6 MULTI-APPLICATIONS – ‘ALTAID’ MECHANISM

The D-PAS application must have the ability to provide multiple AIDs (Aliases) by which the
main payment application may be selected. Each AID must return its own ‘Alias-specific’ FCI
response, but all processing shall be performed by the main D-PAS payment application, using
data items shared by all ‘Alias’ applications. Using the PDOL-check mechanism described in
section 4.3, the AID selected by the terminal may be used to select a particular transaction

‘Profile’, with a ‘profile-specific’ set of CRM elements (Offline counters and limits, AIP, AFL,
and CACs).
The main payment application shall provide the ability to be accessed by using a minimum of
4 different AID values (main AID + 3 Alternate AIDs). These 3 AltAIDs shall be registered in
the main payment application, and when receiving an APDU command, the main application
shall check if the AID originally used to select the application is within its approved AID list. If
the AID value is not in the list, then it shall not be possible to access the main application
using that AID. The Alias application contains an alias-specific FCI (response to SELECT). This
FCI record may contain an ‘Alias-specific’ PDOL list, which may be used to select an ‘Alias-
specific’ set of internal card resources. The maximum number of alternate AIDs is fixed by
implementation constraints and by the design of the smartcard application.
4.3 INITIATE APPLICATION PROCESSING

The D-PAS application shall support ‘Initiate Application Processing’ using the GET
PROCESSING OPTIONS command as described in [EMV 4.2-3].
The AIP and AFL data returned by the D-PAS application in response to a GET PROCESSING
OPTIONS command shall be returned in format 2
The GET PROCESSING OPTIONS command ensures that the following are performed:
• Inform the D-PAS application that the processing of a new transaction has
begun.
• If PDOL Checks are activated, provide to the D-PAS application all terminal-
related transaction-specific information requested in PDOL, and provide an
opportunity for the card to ‘pre-process’ transaction-specific data and then
perform one of three actions:
• Cause the transaction to be immediately declined during 1st GENERATE AC command

(PDOL-Decline check).
• Select a specific ‘Transaction Profile’ with profile-specific AIP, AFL, and CRM values
(PDOL-Profile check). Note: Profile-specific CRM values are used in all subsequent
processing, including following PDOL check.
• Force the current EMV transaction online (PDOL-Online check). If a transaction is

forced online by PDOL processing, all 1st GENERATE AC standard CRM processing is
bypassed, and an immediate ARQC is returned to the terminal.
• Ensure that the D-PAS application provides to the terminal the proper
‘Application Interchange Profile’ (AIP) and a list of files that contain the D-PAS
chip card application data to be used in processing the transaction (AFL). The
AIP and AFL may be transaction profile-specific.
• The D-PAS application shall also increment the ATC, and reset the Card
Verification Results (CVR). The application switches to an ‘INITIALIZED’ state.
The D-PAS application offers a configuration option that provides the ability to specify that the
EMV-standard READ RECORD and GET DATA commands may only be executed after the card
is in an ‘INITIALIZED’ state (i.e., that the GET PROCESSING OPTIONS command has been
performed). This provides an additional level of cardholder data confidentiality and ensures
that the ATC is incremented each time data is read from the card
The issuer has the ability to activate or de-activate the PDOL-check mechanisms by setting
(or clearing) byte 2, bit 4 of the global Application Configuration Options (ACO) element. If

this bit is set, any previously defined PDOL-checks (Decline, Profile, and Online) shall be
executed. If this bit is not set, the card shall not perform any PDOL-check processing
(functionality is disabled). An issuer that chooses not to use the PDOL-check mechanism may
also clear this ACO bit to optimize transaction performance. If the ACO bit is cleared, all PDOL
check-related processing is bypassed.
If ‘PDOL-checks’ are activated, the D-PAS application uses elements requested in PDOL and/or
certain Operating System (OS) internal data elements (such as ‘AID selected’ or ‘type of
APDU interface’), and/or the value of a tagged internal card Data objects, to perform 3 types
of PDOL checks. These checks are always performed in the same sequence:
1. PDOL-Decline checks. Force the card application to deny a transaction, regardless of other
bits set in the CAC-Denial array. (Bit 1 of CVR byte 4 is set, and the equivalent bit in CAC-
default array shall be set by default).
2. PDOL-Profile checks. Allow the card application to select a particular transaction profile
based on internal or terminal resident data values.
3. PDOL-Online checks. Allow the card to force a transaction online, regardless of other CRM
checks performed in GENERATE AC command.
4.4 READ APPLICATION DATA
4.4.1 READ RECORD

The D-PAS application shall support Read Application Data using the READ RECORD command
as described in [EMV 4.2-1] and [EMV 4.2-3].
• The SFI range supported by the D-PAS application shall be as described in [EMV
4.2-1] and [EMV 4.2-3].
• The issuer shall be able to choose the SFI and record numbers for the terminal
file record data. The D-PAS application shall not explicitly specify the SFI and
records used for the terminal record data. This is to allow for flexibility in the
future, where an issuer may wish to move data from one file record to another.
• The issuer shall be able to specify by means of a configuration option if a GET

PROCESSING OPTIONS command is required before terminal file records may
be read.
• It is recommended that the issuer:
• Follow best practices for the number of records and record contents as per EMV
optimization guidelines.
• Place the record containing SDA data early in the file list. This is to optimize
performance of a transaction at a terminal, in that the terminal may start processing
related to offline Card Authentication while still processing READ RECORD commands.
• Place the records containing the CVM list and Public Key (PK) data early in the file list
to facilitate processing overlap in the terminal.
• Minimize the number of file records and maximize the amount of data in each record.
However, the issuer shall be advised to keep in mind that there may be field
integration issues with very long record lengths.

4.4.2 GET DATA

The D-PAS application shall support read access of data items not available in the terminal file
records, or via the GET PROCESSING OPTIONS command by means of the GET DATA
command as described in [EMV 4.2-3].
The issuer shall be able to specify by means of a configuration option (ACO) if a GET
PROCESSING OPTIONS command is required before tagged data items may be read.
4.4.3 ISSUER DEFINED DATA TAGS

The D-PAS application may include optional support for IDDT. If the D-PAS application
supports IDDT, this functionality shall be disabled unless the issuer enables it via ACO.
There shall be 10 global proprietary data tags (IDDT) in the range ‘DF01’ to ‘DF0A’. The size
of each tag shall be configurable at personalization time.
The tags shall be accessible using only the GET DATA command (described in [EMV 4.2-3]).
IDDT access may be configured as:
• Free read
• PIN protected (as specified in access control byte associated with each IDDT )
• Profile ID
IDDT data may be updated using PUT DATA with or without secure messaging for integrity.
The requirement for PUT DATA with or without secure messaging shall be configurable at
personalization time for each IDDT tag.
4.5 OFFLINE DATA AUTHENTICATION

Off-line data authentication is performed by the terminal using a digital signature scheme
based on RSA public key mechanisms, to authenticate the ICC as described in [EMV 4.2-2]
and [EMV 4.2-3].
The D-PAS application may support 3 types of off-line data authentication:
• Static Data Authentication (SDA): the digital signature is static; the terminal
authenticates critical ICC-resident static data.
• Dynamic Data Authentication (DDA): the digital signature is dynamic. This

means the terminal authenticates a cryptogram generated by the card using
transaction-unique data. The terminal also authenticates the static card data.
• Combined DDA/AC Generation (CDA): this method is similar to the DDA

method but the dynamic signature includes Application Cryptogram (AC), and is
performed during the Generate AC command.
To perform DDA and/or CDA methods, the D-PAS chip card must possess a dynamic-RSA
crypto-processor. The ability to perform SDA is mandatory.
The AIP determines which offline data authentication method(s) are supported by the card.
Note: The PDOL mechanism allows the card to force an immediate online transaction if no
common off-line data authentication method is supported by both the card and the terminal.

4.5.1 STATIC DATA AUTHENTICATION

The ability to support SDA is mandatory for the D-PAS application since there are no specific
requirements in the D-PAS chip card OS or application code necessary to support this
functionality. The Signed Static Application Data (SSAD) is generated during the data
preparation / Personalization phase and the terminal uses an issuer defined set of card data
elements to process static data authentication
4.5.2 DYNAMIC DATA AUTHENTICATION

The D-PAS application supports two forms of Dynamic Data Authentication:
• DDA is executed before the Card Action Analysis process and requires that the
ICC generate a digital signature on ICC-resident/generated data and on data
received from the terminal and identified by the ICC Dynamic Data
Authentication Data Object List (DDOL). In case the ICC DDOL is not present a
default Terminal DDOL shall be used, including at least the unpredictable
number.
• CDA is executed at issuance of either the 1st or 2nd GENERATE AC commands

or both. In the case of a TC or ARQC, the ICC generates a digital signature
when CDA is requested. The digital signature is computed with ICC-
resident/generated data (which contains the TC or ARQC), and with data
received from the terminal and identified by the DDOL and the Card Risk
Management Data Object Lists (CDOL1 and/or CDOL2).
The D-PAS application may support the RSA Chinese Remainder Theorem (CRT) algorithm in
order to optimize transaction performance during DDA and enciphered PIN decryption.
Although this method is recommended, it is not mandatory.
4.5.2.1 STANDARD DYNAMIC DATA AUTHENTICATION (DDA) – INTERNAL

AUTHENTICATE
If both card and terminal support the standard DDA method (AIP, PDOL), the D-PAS
application generates a Signed Dynamic Application Data (SDAD) certificate by signing the
terminal dynamic data specified in the DDOL or Default DDOL with the ICC Private Key. This
dynamic signature is included in the INTERNAL AUTHENTICATE command response.
The D-PAS application shall support the INTERNAL AUTHENTICATE command as described in
[EMV 4.2-3], using the ‘format 2’ response.
When DDA is performed, the D-PAS application shall set to ‘1’ the ‘DDA returned’ bit in the
CVR.
4.5.2.2 COMBINED DYNAMIC DATA AUTHENTICATION APPLICATION CRYPTOGRAM

(CDA)
During Card Action Analysis, the D-PAS chip card application shall set either ‘CDA returned in
first GENERATE AC’ or ‘CDA returned in 2nd GENERATE AC’ bit to ‘1’ in the CVR data element
(depending on the GENERATE AC command during which the card generated the CDA digital
signature).
4.6 PROCESSING RESTRICTIONS

The processing restrictions function is performed by the terminal using data elements from
the terminal and the card, as described in [EMV 4.2-3]. This function does not form part of
the card functional specification.

4.7 GET CHALLENGE

If the card supports the Offline Enciphered PIN, the D-PAS application shall support the GET
CHALLENGE command as described in [EMV 4.2-3] to generate an unpredictable number. This
number is used by the terminal to encrypt the offline PIN before sending the VERIFY
command.
4.8 CARDHOLDER VERIFICATION

Cardholder Verification is performed by the terminal, which uses card data to authenticate the
cardholder as described in [EMV 4.2-3].
The payment application supports the following CVMs:
• Offline Plaintext PIN
• Offline Enciphered PIN
• Online PIN
• Signature
• No CVM required
• Combined offline methods with signature
The AIP indicates the ability of the card to support Offline PIN verification.
The D-PAS application plays a role only if Offline PIN CVM is selected.
The optional Offline Enciphered PIN method requires that the D-PAS chip card possess the
ability to perform RSA computations, and thus contains a dynamic-RSA crypto-processor. If
the chip does not have RSA crypto capabilities, the Offline enciphered PIN method is not
available, and this shall be indicated in the ACO data element.
If a D-PAS card supports Offline Enciphered PIN, the issuer may use a specific ICC PIN
Encipherment public/private key pair, for PIN decryption, or may use the same ICC
public/private key pair as is used for DDA. This issuer choice is specified via a configuration
option in the ACO data element.
If Offline Enciphered PIN or Offline Plaintext PIN verification is supported by the card, the D-
PAS application shall support the VERIFY command as described in [EMV 4.2-3].
The VERIFY command initiates the card comparison of the cardholder-entered transaction PIN
with the Reference PIN stored on card.
Depending on the CVM requested by the terminal, the PIN Try Counter value and the CVM
checks, the D-PAS application shall set the following indicators in the CVR Table:
• Offline Enciphered PIN Verification performed
• Offline PIN Verification performed
• Offline PIN Verification successful
• Offline PIN Verification failed
• PIN Try Limit Exceeded
• PIN Try Counter Value

4.9 TERMINAL RISK MANAGEMENT

Terminal Risk Management Verification is performed by the terminal using card data as
described in [EMV 4.2-3].
The D-PAS application does not play a role in Terminal Risk Management.
4.10 TERMINAL ACTION ANALYSIS

Terminal Action Analysis is performed by the terminal using terminal and card data to
determine whether the transaction should be approved offline, declined offline, or sent online
for an authorization, as described in [EMV 4.2-3].
The D-PAS application shall provide to the terminal the Issuer Action Codes (Denial, Online,
Default), but does not play a role in Terminal Risk Management.
4.11 FIRST CARD ACTION ANALYSIS

First Card Action Analysis allows issuers to perform velocity checking and other risk
management checks that are internal to the card. Card Risk Management features described
in this section include checking:
• Information on the Previous Transaction History (PTH)
• Offline transaction counters and limits
• Single Transaction Amount (STA) limit
• Specifics of the current transaction (CVR compared with CACs)
After completing Card Risk Management, the card logs the transaction (configuration option)
and returns an Application Cryptogram to the terminal. This cryptogram is:
• An AAC for an offline decline
• An ARQC for a request for an online authorization
• A TC for an offline approval
If supported by both the card and terminal, the terminal may request CDA. If so, an ARQC or
TC shall be returned as part of a dynamic signature computed by the card.
Card Action Analysis is performed as follows:
During the 1st Generate AC command, the D-PAS application performs the following actions:
1. Analyze CDOL1 Data, and perform Card Risk Management tests to determine if the
transaction must be declined, must go online, or may be accepted offline.
2. Generate an Application Cryptogram using session keys derived from issuer-specific

master-keys. This AC may be a TC, an ARQC, or an AAC. The response to the Generate AC
command shall be in ‘format 2’, as described in section 6.5.5.4 of [EMV 4.2-3].
3. When a cryptogram is requested (ARQC), the card must also generate ‘Issuer Application
Data’ containing Derivation Key Index (DKI), Cryptogram Version Number (CVN), Card
Verification Results (CVR), and (optionally) the contents of additional tagged elements
[such as Number of Consecutive Offline Transactions (NCOT) and Cumulative Offline
Amount (COA)], then insert this into the GENERATEC AC response data. The actual
contents of Issuer Application Data depend on the contents of an IADOL which is
personalized by the issuer. By default, issuer application data contains the DKI, CVN, and

CVR, but the contents of IAD may be modified by adding tag values for particular internal
card data elements into the internal IADOL list. Note: This offers the issuer the ability to
evaluate the values stored in IDDT data (for example) during an authorization request, as
well as the current value of profile-defined offline counters.
4. If an ARQC is returned, the card is in an ‘ONLINE’ Application State, and expects a 2nd
‘GENERATE AC’ command with issuer response. A configuration option element in ACO
allows the issuer to specify whether ARQC transaction specifics shall be ‘Pre-logged’ in the
Transaction Log file. If this option is set, the card creates a Transaction Log record for the
current transaction, containing the ARQC cryptogram. If a 2nd GENERATE AC command is
received, this Transaction Log record is overwritten with the final Transaction Log record
containing TC or AAC.
5. If a TC is generated (transaction accepted offline), a ‘Transaction Log record’ is created,

containing Transaction specific data, including cryptogram and CVR. The application is now
in a ‘SCRIPT’ Application State and will accept issuer scripted commands.
6. If an AAC is generated (transaction declined), a configuration option permits the issuer to

request that an AAC transaction shall be logged. If this configuration option is set in ACO,
the card generates a Transaction Log file record before responding to the terminal. The
application is now in a ‘SCRIPT’ Application State, and will accept issuer scripted
commands.
The card performs a series of ‘Risk Management’ tests on current transaction to determine
whether the level of offline risk is acceptable. This process of CRM in the D-PAS application is
performed partly during the GET PROCESSING OPTIONS command (pre-processing) and
partly during the GENERATE AC command.
The first step of the CRM process during the GENERATE AC command consists of the card
registering events that occurred in the previous transaction by checking the bits set in the
PTH (in particular the ‘Go Online next transaction’ bit) and then updating the CVR with the
values stored in PTH . The PTH is then reset.
If the terminal does not request an AAC in the 1st GENERATE AC command, the card first
compares the CVR with the contents of the CAC-Denial array. If the same bit is set both in the
CVR and in the CAC-Denial array, the card returns an AAC (transaction declined) and shall not
perform any additional Card Risk Management tests. If the issuer configuration option has
been enabled, a Transaction Log record may be created for the denied transaction. Note:
‘GPO pre-processing’ may have previously set the ‘PDOL forced decline’ bit in the CVR (bit 1,
Byte 4), which may result in an automatic decline, since the equivalent bit in CAC-Denial
should always be set.
If the terminal does not request an AAC in the 1st GENERATE AC command, and if ‘GPO pre-
processing’ or ‘PTH processing’ has set either the ‘PDOL forced online’ or ‘PTH forced online’
bits in the CVR, all normal ‘1st GENERATEC AC’ risk management tests are bypassed, and the
card returns an ARQC response. If neither of these two CVR bits has been set, standard Risk
Management tests take place, using the CVR, CDOL1 data, and the ‘CAC-Online’ array.
The CAC arrays follow the structure of CVR bytes 4 and 5, and code all circumstances under
which the issuer may wish a transaction to be declined (CAC Denial), go online (CAC Online),
or be declined if online authorization request is not possible (CAC Default). The structure of
CVR and CAC arrays are documented in Appendix B.
Card Risk Management tests are of two types:
1. Velocity Checking, and
2. Events occurring in current or past transaction.

4.11.1 VELOCITY CHECKING

Velocity checking consists in evaluating the number, or cumulative value amount of previous
consecutive offline transactions, occurring since the last ‘Online authorization’ request and
response. The number of consecutive transactions is recorded in one or more ‘NCOT’
counter(s) maintained by the card, while the Cumulative amount of offline transactions is
recorded in a global ‘COA’ counter. The amount of the current transaction is also evaluated
against the value of the ‘Single Transaction Amount Limit’.
The COA counter is always global, in that it accumulates all offline transaction amounts,
regardless of which transaction profile was used by the card application. The amount of the
current transaction (if known) is added to the contents of the global COA before comparing
COA with the profile-specified Lower Cumulative Offline Transaction Amount Limit (LCOA) and
Upper Cumulative Offline Amount Limit (UCOA). If the new COA value exceeds one of the two
offline limits, a specific bit in the CVR is set, and the CVR is then compared with the issuer-
specified actions coded in the CAC arrays. The personalization values of the CAC arrays
dictate whether the card will decline, accept, or request an online transaction, based on the
cumulative amount of consecutive offline transactions.
By default, the NCOT counter counts the number of consecutive offline transactions of all
types, regardless of currency code or issuer country code. However, if so desired, a
configuration option allows the issuer to specify that NCOT counters shall only count
transactions where the transaction currency is not recognized.
The NCOT counter may be specific to the current transaction profile. If transaction profiles
are not defined by the issuer, the NCOT in the ‘default profile’ shall be used for all
transactions, unless bit 3 of the PRU byte for ‘Profile 0’ is set. However, using the PDOL-
Profile pre-processing mechanism, ‘Domestic’ and ‘International’ transactions may be
managed using different transaction profiles, with separate NCOT counters and limits.
The profile-specified NCOT counter is always incremented by 1 before NCOT is compared to

Lower Consecutive Offline Limit (LCOL) and (Upper Consecutive Offline Limit (UCOL). If the
new NCOT value exceeds one of the two offline limits, a specific bit in the CVR is set, and the
CVR is then compared with the issuer specified actions coded in the CAC arrays. The
personalization values of the CAC arrays dictate whether the card declines, accepts, or
requests an online transaction, based on the number of consecutive offline transactions of
that same type occurring.
If the issuer chooses to use the ‘PDOL-Profile’ mechanism, each Transaction Profile may
potentially contain the following:
• A NCOT counter specific to the profile,
• A set of Offline limits specific to the profile, and containing:
o LCOL,
o UCOL
o LCOA limit
o UCOA limit
o STA
• A set of three CAC arrays, specific to the profile
• A profile specific AFL and AIP

Profile-specific LCOL and UCOL limits may work in association with either a profile-specific
NCOT counter, or a global (profile 0) NCOT counter. Use of NCOTs in transactions with
recognized currencies is an issuer configuration option. Profile-specific UCOA and LCOA limits
always work in association with the global COA counter, and may only be used when a
transaction currency is recognized.
If the issuer chooses to not use transaction profiles, or the current transaction specifics do not
merit the use of a specific transaction profile, the CRM objects defined in a default ‘Profile 0’
object are used.
4.11.2 PREVIOUS AND CURRENT TRANSACTION EVENTS

In addition to transaction frequency and cumulative amounts, the D-PAS application also
performs some Card Risk Management checks based on certain events occurring in the
current or the previous transaction. These events may include such things as failed PIN
verification, failed Issuer Authentication, or Scripts received or failed, and may be coded
either in the CVR (current transaction), or in the PTH (previous transaction).
Card Risk Management is performed by comparing the contents of the CVR with 3 CAC arrays.
The CAC arrays follow the structure of CVR bytes 4 and 5.
During the 1st GENERATE AC ‘Card Risk Management’ process, the card first initializes CVR
with contents of PTH, then compares the CVR and the CAC-Denial array. If a match is found,
the card declines the transaction by returning an AAC. If no match was found between CVR
and CAC-Denial array, the card verifies bits 2-3 of CVR byte 4 (B4b3-2). If either of these
two bits are set [‘PTH forced Online’, or ‘PDOL forced Online’], the card bypasses all other
CRM checks, does not increment the offline counters, and returns an ARQC and Issuer
Application Data.
Note: If offline counters are inserted into Issuer Application Data, these shall not include the
current transaction or transaction amount.
Note: A slight decrease of transaction performance may occur because many CRM checks are
bypassed when a transaction is forced online by the PDOL mechanisms.
If GPO pre-processing has resulted in the selection of a particular transaction profile, the
selected ‘Profile ID’ is inserted in bits 1-4 of CVR byte 6. If the ‘Profile selection’ mechanism
is not being used by the issuer, or if no particular profile was selected, these bits default to a
value of ‘0000’.
If GPO PDOL-Decline or PDOL-Online pre-processing has resulted in the transaction being

declined or forced online, the ID of the PDOL check which forced the decline or online
transaction is inserted in bits 5-8 of CVR byte 6. If the ‘PDOL-Decline’ and ‘PDOL-Online’
mechanisms are not being used by the issuer, or if transaction has not been affected by PDOL
checks (forced decline or forced online), these bits default to a value of ‘0000’.
If the transaction was not forced online by either CVR byte 4 bit 2 or 3, the card proceeds
with standard risk management checks, by comparing the global COA with profile-specific
LCOA and UCOA, the current ‘Transaction Amount’ with the ‘Single Transaction Amount Limit’,
and the profile-specific NCOT counter with profile-specific LCOL and UCOL. The proper bits in
the CVR are set if any of the limits are exceeded. The CVR is then compared with the CAC-
Denial array:
1. If the same bit is set in both CVR bytes 4 or 5, and in the CAC-Denial array, the card
declines the transaction, and returns an AAC cryptogram.
If there is no match, the CVR is then compared with the CAC-Online array:

1. If the same bit is set in both CVR bytes 4 or 5, and in the CAC-Online array, the card
requests an online transaction, and returns an ARQC cryptogram.
2. If an Offline acceptance (TC) was requested, and no match was found between CAC arrays
and CVR bytes 4 and 5, the card accepts the transaction offline, and returns a TC
cryptogram.
Before returning the final AC the card (optionally) creates a Transaction Log record, which
records transaction specific data in a cyclic record file that may be read by the issuer using a
dedicated terminal. See section 4.13 for a description of the Transaction Logging sequence
and options, as well as a list of the data elements which are logged.
The card also changes its internal ‘Application State’ from ‘INITIALIZED’ to one of the
following:
• TC or AAC returned: Application State: ‘SCRIPT’
• ARQC returned: Application State: ‘ONLINE’
4.12 SECOND CARD ACTION ANALYSIS

The 2nd GENERATE AC command serves four main purposes:
1. It conveys the issuer response (Approve or Decline) to an online authorization request

previously generated by the card application.
2. It allows the card to perform Issuer Authentication to verify that the authorization
response was, in fact, generated by the issuer host.
3. It allows the card to create a final Transaction Log file record and update internal data
elements such as offline counters and PIN Try Counter (PTC).
4. It allows the card to perform further (contingency) card risk management, when the
terminal is unable to go online, but has received a previous online authorization request.
Regardless of the outcome of the 2nd GENERATE AC command (TC or AAC), the D-PAS
application shall thereafter be in an application-state of ‘SCRIPT’, and is ready to receive any
issuer scripts that may have been contained in the authorization response message.
4.12.1 ISSUER AUTHENTICATION

In the D-PAS application, Issuer Authentication takes place during the 2nd GENERATE AC
command. (Note: The EXTERNAL AUTHENTICATE command shall not be provided by the DCI
payment application.)
Issuer authentication data is generated by the issuer host, using a card-specific 3DES key,
and is sent to the card in the 2nd GENERATE AC APDU command data. The card is
responsible for verifying the cryptogram generated by the issuer host based on the results of
this verification and an issuer configuration option (stating whether issuer authentication is
mandatory). If verified, the card shall return a TC cryptogram (transaction approved) or an
AAC cryptogram (transaction declined) to the terminal device.
In circumstances where only a partial-grade EMV infrastructure exists, the card application
may not receive all the ICC data normally conveyed in the DE-55 field of the authorization
response message (in particular, the ‘Issuer Authentication Data’). To prevent transaction
failures under these conditions, the card offers a configuration option (‘Issuer Authentication
Mandatory’) that instructs the card to accept an authorization response, even if Issuer
Authentication Data is not present, or if Issuer Authentication Data fails because of message

corruption/truncation. Other configuration options allow the issuer to specify whether Issuer
Authentication is mandatory before re-setting offline and script counters. (See Appendix A for
a description of ACO Issuer Authentication-related options available.) Note 1: If Issuer
Authentication Data is not received but Issuer Authentication is not mandatory to reset
counters, all profile-specified offline counters and script counter are automatically reset.
Offline counters used in other transaction profiles are not affected. Note 2: If Issuer
Authentication Data is not received, the application uses 10 byte of '00' to represent issuer
authentication data in CDOL2.
If Issuer Authentication Data is present and is valid, the card processes the Card Status
Update (CSU) value contained in authentication data. Based on the bits set in this variable,
the card sets offline counters to a predetermined value, sets certain bits in the PTH data
element, resets Script counter [or not], and/or sets PIN Try Counter (PTC) to a specified
value.
4.12.2 UNABLE TO GO ONLINE

In certain cases, the card application returns an ARQC during the 1st GENERATE AC
command, indicating ‘Online authorization request required’, but because of network or issuer
host difficulties, the terminal is unable to complete the ‘Online’ transaction. In this instance,
the terminal sends an Authorization Response code to the card during the 2nd GENERATE AC
command of:
• ‘Y3’’ if ‘TC’ is requested by terminal, or
• ‘Z3’ if ‘AAC’ is requested by terminal.
Note: The Terminal’s decision on whether to request TC or AAC depends on a second round
of Terminal Risk Management performed with the IAC-default array and TVR setting [EMV
4.2-4].
If the results of 2nd Terminal risk management have resulted in a TC request, the card must
now decide whether to accept the transaction despite the fact that the terminal was unable to
complete the online authorization request. This decision is taken after a second round of Card
Risk Management checks, performed with the ‘CAC default’ array and the transaction specifics
recorded in the CVR. Note: If the terminal type is ‘CAT3’ (Offline-only cardholder activated),
there is an ACO configuration option that allows the issuer to specify that CAC-Default checks
shall not be performed when an ‘Unable to go online’ message is received .If the CAC-Default
array is disregarded in the case of a CAT3 terminal Byte2, bit 2 of the CVR shall be set
The structure of the ‘CAC-default’ array is identical to that of the ‘CAC-Denial’ and ‘CAC-
Online’ arrays, as well as CVR bytes 4 and 5. The second card risk management process is
based on the results of a comparison performed between the bits set in CAC-default, and the
bits set in CVR bytes 4 and 5. If the same bit is set in the two byte arrays, the transaction is
declined offline, and the card returns an AAC. If no matching bits are found, the card accepts
the transaction offline and returns a TC.
Note: The bits set in ‘CAC-default’ are usually different from those set in ‘CAC-online’, to
permit contingency offline acceptances when the issuer host or network is down.
Offline counters and PTC are not affected in the case when the terminal is unable to go online,
since a completed Online authorization request-response transaction has not occurred.
4.13 TRANSACTION LOGGING

The D-PAS application supports Transaction Logging as described in the First Card Analysis
section 4.11.

The Transaction Log file is a global file having a cyclic structure with records of fixed length.
Record #1 corresponds to the most recent transaction. Record #2 is the next most recent
transaction, etc.
Logging occurs during the 1st GENERATE AC command for transactions approved or declined
offline. For transactions processed on-line, a pre-logging of ARQC data may take place during
the 1st GENERATE AC command (configuration option). A final Transaction Log record is
created during 2nd GENERATE AC command (over-writing the pre-logged record), if the 2nd
GENERATE AC command is subsequently received by the card. This allows Transaction Log
records to be created when an online authorization request is made, and the receipt of 2nd
GENERATE AC command is not received.
Each entry of the Transaction Log file consists of the concatenation of transaction related
values identified in the ‘Log Format’ data element (Tag 9F4F). Information about the location
(SFI) of the log file and the maximum number of log records is specified in the Transaction
Log Entry data element (Tag 9F4D).
The D-PAS application shall be able to log the following types of transactions, based on the
configuration options.
Table 7 - Transaction Logging Configuration Options
Option Description
Log Declined offline and online This option indicates whether a transaction is logged if the D-
Transactions (AACs) PAS application responds with an AAC to the GENERATE AC
command. This option applies to logging during both the 1st
and 2nd GENERATE AC command processing.
Log Approved Transactions This option indicates whether a transaction is logged if the D-
PAS application responds with a TC to the 1st or the 2nd
GENERATE AC command.
Log on-line authorization This option indicates whether a transaction is logged if the D-
requests (pre-log ARQC) PAS application responds with an ARQC to the 1st GENERATE
AC command. If a 2nd Generate AC is subsequently received,
the final Transaction Log record shall overwrite the pre-logged
transaction data.
4.14 ISSUER SCRIPT COMMAND PROCESSING
The D-PAS application shall support the following Issuer Script Commands:
• APPLICATION BLOCK
• APPLICATION UNBLOCK
• PIN CHANGE/UNBLOCK
• PUT DATA
• UPDATE RECORD

• CARD BLOCK (platform optional)
Script commands shall be accepted when the card is in a ‘SCRIPT’ state, i.e., after a TC or
AAC is returned in response to a 1st or 2nd GENERATE AC command (tag ‘72’ scripts). No tag
’71’ scripts (executed between 1st and 2nd GENERATE AC commands) shall be accepted by
the card application.
The D-PAS application supports Format 2 for the secure messaging used in issuer scripted
commands. Format 2 Secure Messaging is described in [EMV 4.2-3].


5 COMMON APDU COMMAND PROCESSING

All application transactions comply with [ISO7816-4] at both the Application Protocol Data
Unit (APDU) and Transmission Protocol Data Unit (TPDU) level. Only the application level is
defined in this specification. To obtain information on how the card APDUs are transmitted as
TPDUs, refer to [ISO7816-4], and in particular to the details of the GET RESPONSE procedure
used to allow case 4 APDUs to be transmitted in T=0.
5.1 APDU COMMAND COMPONENTS

Elements
As defined in [ISO7816-4], each command contains the following elements at the APDU level:
• A header, composed of the four bytes CLA, INS, P1, P2
• Lc, the command data block length, which may be present
• A command data block, which may be empty
• Le, the expected response data block length, which may be present
Response
Each APDU response consists of:
• A response data block, which may be empty
• Status bytes SW1, SW2
5.2 COMMON APDU COMMAND RESPONSES

Card readers, terminals or Interface Devices (IFDs) shall always send a CLA byte of 0x00,
0x80, or 0x84 (depending on specific APDU command) after application selection. If any other
CLA byte is used, the card returns an ISO-specified error status of ‘6E00’.
The INS byte is different for different transactions and is explicitly shown for each transaction.
If any undefined INS byte is used, the application returns an error status of ‘6D00’.
IFDs shall always send a P1 byte of zero unless the description of the transaction explicitly
states otherwise. If the application receives a non-zero P1 byte for a transaction which does
not use the P1 byte, the application returns an ISO-specified error of ‘6A86’.
IFDs shall always send a P2 byte of zero unless the description of the transaction explicitly
states otherwise. If the application receives a non-zero P2 byte for a transaction which does
not use the P2 byte, the application returns an ISO-specified error of ‘6A86’.
The lengths (or maximum values of the lengths) of the command data block (Lc) and
response data block (Le) are explicitly shown for each transaction. These lengths must be no
greater than 255.
• Only the exact value of Lc or a length up to the maximum allowed length is acceptable.
The application may return an ISO-specified error of ‘6700’ if Lc is incorrect.
• Except in a case 4 commands or when Le = '00' only the exact value of Le is acceptable.
The application returns an ISO-specified error of ‘6Cxx’ (with ‘XX’ indicating the proper Le)
if any other value is supplied.

Before processing the received command, the D-PAS application verifies the following
conditions:
Operation Error
• Verify application not disabled (due to counters, e.g., ATC reaching their limit) ‘6985’
• Verify in the D-PAS application that the AID selected by the terminal is that of ‘6985’
the main payment application (this AID of this application) or is registered in the
main payment application (is registered in this application).
• Check CLA ‘6E00’
• Check INS ‘6D00’
• Process the command ‘6xxx’1

1
See following command specification.
Note: The flow charts in the following sections illustrate a recommended command
processing sequence that is not mandatory. It is understood that processing sequences
may be to a certain degree implementation-specific, and that the actual processing sequence
implemented may differ somewhat from the sequence illustrated.
The generic processing flow is illustrated in the following diagram.

APDU
(CLA, INS, P1, P2)
received
Valid AID
SW12
receiving No
‘6985’
APDU?
Yes
Application SW12
Yes
disabled? ‘6985’
No
CLA byte SW12

No
valid? ‘6F00’
Yes
SW12
INS byte valid? No
‘6D00’
Yes
This check may be specific

to the APDU LC or Le
Yes 6700 or 6CXX
incorrect?
No
Command specific
processing
Figure 3 - Generic Command Processing Flow

5.3 APDU COMMAND SUMMARY TABLE
Table 8 - APDU Command Summary Table
Command CLA INS P1 P2 Lc/Le Remarks
ISO commands
GET RESPONSE ‘00’ ‘C0’ ‘00’ ‘00’ Le = Var. Required for T = 0 ISO case 4
commands protocol. Le = XX in 61XX
code returned by last (case 4)
command.
SELECT DF ‘00’ ‘A4’ ‘04’ ‘00’/ Lc = Var. Lc = Length of AID
‘02’
Le = ’00’ Final Le = Length of FCI
(Var)
PUT DATA ‘84’/ ‘DA’ Tag Lc = Var. Tag number coded in P1-P2, Lc =
length of tagged data object + 8 (if
‘80’
secure messaging required)
EMV Commands
APPLICATION ‘84’ ‘1E’ ‘00’ ‘00’ Lc = ’08’

BLOCK
APPLICATION ‘84’ ‘18’ ‘00’ ‘00’ Lc = ’08’
UNBLOCK
CARD BLOCK ‘84’ ‘16’ ‘00’ ‘00’ Lc = Var. Not available on all platforms
GET CHALLENGE ‘00’ ‘84’ ‘00’ ‘00’ Le = ’00’ The response data is an 8-byte
unpredictable number. Le may be ‘08’.
GET DATA ‘80’ ‘CA’ Tag Le = ’00’ Tag number coded in P1-P2
(Var)
Final Le=vary by tag
GENERATE AC ‘80’ ‘AE’ Var. ‘00’ Le = ’00’ Lc=Length of CDOL1 data
(Var)
Final Le=vary by presence of IADOL
Lc = Var. and length of IAD
GET PROCESSING ‘80’ ‘A8’ ‘00’ ‘00’ Lc = Var. Lc depends on contents of PDOL list.
OPTIONS
Final Le=vary by length of AFL
INTERNAL ‘00’ ‘88’ ‘00’ ‘00’ Lc = Var. Lc depends on length of Authentication-
AUTHENTICATE related data. Lc = ’04’ if only
unpredictable number is used.
Final Le=vary by length of ICC_PK
Modulus
Only available if card is RSA capable.
PIN ‘84’ ‘24’ ‘00’ ‘00’/ Lc = Var. P2=00 for unblock, P2=02 for PIN
CHANGE/UNBLOC ‘02’ change. Lc=08 for Unblock and Lc=16
K (0x10) for PIN Change
READ RECORD ‘00’ ‘B2’ Var. Var. Le = ’00’ P1= Record number, P2= Reference
(Var) Control Parameter.

Command CLA INS P1 P2 Lc/Le Remarks
Final Le=length of record data

UPDATE RECORD ‘84’ ‘DC’ Var. Var. Lc= Var. P1= Record number, P2= Reference
Control Parameter. Lc = Length of
Record Data + 8 bytes of MAC
VERIFY ‘00’ ‘20’ ‘00’ ‘80’/ Lc var P2=’80’ for plaintext PIN, P2=’88’ for
‘88’ encrypted PIN, Lc= PIN Len
CPS Commands
EXTERNAL ‘84’ ‘82’ Var. ‘00’ Lc = ’10’ Host cryptogram and command MAC
AUTHENTICATE
INITIALIZE ‘80’ ‘50’ Var. ‘00’ Lc = ’08’
UPDATE
STORE DATA ‘80’ ‘E2’ Var. Var. Lc = Var. Personalization data in plaintext
‘84’ Encrypted personalization data and
MAC
Legend
Secure Messaging required

ISO ‘Case 4’ command
The following section provides more details on each of these APDU commands.


6 APPLICATION COMMANDS
This section describes the APDU commands supported by the application. Each command is
presented within a common format, with up to seven of the following subheadings;
1. Definition and Scope -Provides a definition of the purpose and effect of the
command under discussion.
2. Command APDU - Contains details of the command header, the associated length
parameters and any data that should be sent as part of the command.
3. Data Field Returned in the Response Message - Provides responses provided by
each command.
4. Processing State Returned in the response Message - Describes error conditions
returned by a command.
5. Transaction Flow – Contains a diagram that shows the processing flow inside the
ICC. These examples are not meant to be restrictive, in that other methods of meeting
the same function requirements may also be considered.
6. Notes - If present, provide further useful information pertaining to the operation of a

command on the Transaction Flow diagram noted in item 5 of this list.
7. Example - Provides an example of command processing behavior.
6.1 APPLICATION BLOCK
6.1.1 DEFINITION AND SCOPE

An APPLICATION BLOCK command is an issuer script command that invalidates the currently
selected application.
An application that has been blocked shall return the status bytes SW1 SW2 = '62 83' in
response to a SELECT command.
If an application has been blocked, it continues to process a transaction but shall always
return an AAC in response to a GENERATE AC command.
6.1.2 COMMAND APDU

The APPLICATION BLOCK command is coded as shown in Table 9.
Table 9 - APPLICATION BLOCK Command
Code Value
CLA '84'
INS '1E'
P1 '00'
P2 '00'
Lc '08'
Data MAC
Le Not Present

6.1.3 DATA FIELD RETURNED IN THE RESPONSE MESSAGE

No data field is returned in the response message.
6.1.4 PROCESSING STATE RETURNED IN THE RESPONSE MESSAGE

In addition to the error codes listed in section 5.2 , the status words in Table 10 shall be
returned in response to the command. The resulting application state is also shown.
Table 10 - APPLICATION BLOCK Status Words and Application Final State
Resultant
SW1 SW2 State Value
'90 00' SCRIPT Command completed successfully

’69 88’ SELECTED Incorrect secure messaging data objects
'69 85' SELECTED Conditions of use not satisfied
'6A 86' SELECTED Incorrect parameters P1-P2

6.1.5 TRANSACTION FLOW
Figure 4 - APPLICATION BLOCK Transaction Flow Diagram

6.1.6 NOTES
S0
The Failed MAC, Session MAC and Lifetime MAC counters are incremented. The Failed MAC
counter is decremented when the MAC is correctly verified.
S1
The command MAC is verified as specified in section 7.3.
S2
The ‘Script Failed’ bit in PTH (B1b1) is set by default, and only cleared when the command is
successful. Any error condition should thus result in a ‘Script Failed’ bit of PTH being set.
6.1.7 EXAMPLE
Table 11 - APPLICATION BLOCK Command Example
Command APPLICATION BLOCK
Parameters None
Details • AC is '1234 1234 1234 1234' and this is the 4th script command in the
session
• Session key for SM is thus: ‘7A36C671D15746BE 3F1398136AFD9546’
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
• The following are concatenated to build input to MAC calculation:
o Command header = ‘841E000008’;
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1237’ (AC+3);
o Padding to 8 byte boundary.
• The input blocks are thus:
o D1 = ‘841E000008123412’
o D2 = ‘3412341234123780’
• The output blocks are thus:
o O1 = ‘FA4268BEB51D7FBC’
o O2 = ‘AD966F32F5FB8AE2’
o O3 = ‘10654A884F5C68A5’
o O4 = ‘F9F2F1A6B581490D’
• The MAC is thus O4 = ‘F9F2F1A6B581490D’
CLA INS P1 P2 Lc Data Le
'84' '1E' '00' '00' '08' 'F9F2F1A6B581490D’ Not present

Table 12 - APPLICATION BLOCK Response Example
Response APPLICATION BLOCK
Parameters None
Details Application is blocked
Data SW1 SW2
Not present '90 00'
6.2 APPLICATION UNBLOCK

An APPLICATION UNBLOCK command is an issuer script command that rehabilitates the
currently selected application.
After the successful completion of an APPLICATION UNBLOCK command, the restrictions

imposed by the APPLICATION BLOCK command are removed.
This command is only available in the SCRIPT state.
6.2.2 COMMAND APDU

The APPLICATION UNBLOCK command is coded as shown in Table 13.
Table 13 - APPLICATION UNBLOCK Command
Code Value
CLA '84'
INS '18'
P1 '00'
P2 '00'
Lc '08'
Data MAC
Le Not Present



In addition to the error codes listed in section5.2, the status words in Table 14 shall be
Table 14 - APPLICATION UNBLOCK Status Words and Application Final State
Resultant
SW1 SW2 State Value


Figure 5 - APPLICATION UNBLOCK Transaction Flow Diagram

6.2.6 NOTES
S0
S1
S2
6.2.7 EXAMPLE
Table 15 - APPLICATION UNBLOCK Command Example
Command APPLICATION UNBLOCK
Parameters None
Details • AC is '1234 1234 1234 1234' and this is the 1st script command in the
session
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
o Command header = ‘8418000008’;
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1234’ (AC);
o D1 = ‘8418000008123412’
o D2 = ‘3412341234123480’
o O1 = ‘A43298E2D8F3DCE3’
o O2 = ‘17C96E54E8479BD9’
o O3 = ‘80E183470CEF96D9’
o O4 = ‘33F580805A567C6C’
• The MAC is thus O4 = ‘33F580805A567C6C’
'84' '18' '00' '00' '08' '33F580805A567C6C’ Not present

Table 16 - APPLICATION UNBLOCK Response Example
Response APPLICATION UNBLOCK
Parameters None
Details Application is unblocked
Data SW1 SW2
Not present '90 00'
6.3 CARD BLOCK

CARD BLOCK is an issuer script command that permanently disables all applications in the
ICC.
The CARD BLOCK command shall disable all applications in the ICC, including applications that
may be selected implicitly.
Following the successful completion of a CARD BLOCK command, all subsequent SELECT
commands shall return the status bytes SW1 SW2 = '6A81' (Function not supported) and
perform no other action.
6.3.2 COMMAND APDU

The CARD BLOCK command is coded as shown in Table 17.
Table 17 - CARD BLOCK Command
Code Value
CLA '84'
INS '16'
P1 '00'
P2 '00'
Lc Var.
Data (OS MAC) + 8-byte MAC
Le Not Present
The CARD BLOCK command may use the underlying operating system’s card block function to
disable applications. As such, the actual contents of APDU data are outside the scope of these
specifications. When the card is blocked, all applications shall not be selectable. If the card OS

does not support the ‘Card Block’ functionality and a correctly scripted ‘Card Block’ command
is received, at a minimum the D-PAS application must be blocked.
Note: By blocking the application and not returning an error response when the card OS does
not support the Card block functionality, the ‘minimal intent’ of the issuer scripted
command is accomplished, and further scripted commands may still be sent to the card.


In addition to the error codes listed in section 5.2, the status words in Table 18 shall be
Table 18 - CARD BLOCK Status Words and Application Final State
Resultant
SW1 SW2 State Value


Figure 6 - CARD BLOCK Transaction Flow Diagram

6.3.6 NOTES
S0
S1
S2
The CARD BLOCK command may use the underlying operating system’s card block function to
disable applications. The checking of OS MAC is a function provided by the card operating
system and is outside the scope of this specification.
S3

Example
Table 19 - CARD BLOCK Command Example
Command CARD BLOCK
Parameters None
Details • AC is '1234 1234 1234 1234' and this is the 1st script command in the
session
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1234’ (AC);
o OS MAC = ‘31B2 C75E D312 8854’;
o D1 = ‘8416000010123412’
o D2 = ‘3412341234123431’
o D3 = ‘B2C75ED312885480’
o O1 = ‘B2F33446C4AE11BE’
o O2 = ‘A66DD9F8DE5D2EF0’
o O3 = ‘35653F86627C70F5’
o O4 = ‘81F38CEDD61179A3’
o O5 = ‘A019FD61B4A564BE’
• The MAC is thus O5 = ‘A019FD61B4A564BE’
'84' '16' '00' '00' '10' '31B2C75ED3128854 A019FD61B4A564BE’ Not present

Table 20 - CARD BLOCK Response Example
Response CARD BLOCK
Parameters None
Details Card is blocked
Data SW1 SW2
Not present '90 00'
6.4 GENERATE APPLICATION CRYPTOGRAM

The GENERATE AC command is used to send transaction specific data to the ICC, which
processes and returns a cryptogram. The cryptogram returned may be any one of the
cryptograms specified in Table 21.
Table 21 - GENERATE AC Cryptogram Types
Cryptogram Type Meaning
Application Authentication Cryptogram (AAC) Transaction declined

Transaction Certificate (TC) Transaction approved
Authorization Request Cryptogram (ARQC) Online authorization requested.
6.4.2 COMMAND APDU

The GENERATE AC command is coded as shown in Table 22.
Table 22 - GENERATE AC Command
Code Value
CLA '80'
INS 'AE'
P1 Reference Control parameter (refer to Table 23)
P2 '00'
Lc Var.
Data Transaction-specific data
Le '00'

Table 23 - GENERATE AC Reference Control Parameter
Reference Control Parameter
Bit 8 Bit 7 Bit 6 Bit 5 Bit 4 Bit 3 Bit 2 Bit 1 Meaning
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - ARQC
1 1 - - - - - - Reserved for Future Use
(RFU)
- - X - - - - - RFU
- - - 0 - - - - CDA not requested
- - - 1 - - - - CDA requested
- - - - X X X X RFU
As shown in Table 23, parameter P1 indicates the type of cryptogram requested by the
terminal and whether the transaction is eligible for CDA cryptogram generation. The
cryptogram returned by the ICC may be different from the one requested depending on ICC
internal processing.
The APDU command data contains the data specified in the CDOL1 in case of GENERATE AC1
or CDOL2 in case of GENERATE AC2.
Note: If an application has been blocked, it returns an AAC in response to this command.

The data field returned in the response message shall be constructed as per EMV format 2: A
constructed data object with BER-TLV tag equal to ‘77’. The value field shall consist of several
Basic Encoding Rules-Tag Length Value (BER-TLV) coded objects.
If the response is as a result of "CDA not requested", the response will be as specified in
Table 24. If the response is as a result of "CDA requested", the response will be as specified
in Table 25 or Table 26.
Table 24 - GENERATE AC Response Data Field, CDA not requested
Tag Description Tag Presence
Cryptogram Information Data (CID) 9F27 Mandatory

Application Transaction Counter (ATC) 9F36 Mandatory
Application Cryptogram (AC) 9F26 Mandatory
Issuer Application Data (IAD) 9F10 Mandatory (may contain optional IADOL-
specified elements)

Table 25 - GENERATE AC Response Data Field for TC or ARQC, CDA requested

Signed Dynamic Application Data 9F4B Mandatory
specified elements)
Table 26 - GENERATE AC Response Message Data Field for AC, CDA requested

Application Cryptogram (AC) 9F26 Mandatory
specified elements)
If any of these mandatory data elements are missing, the terminal shall terminate the
transaction.
For both formats, the Cryptogram Information Data returned by this command shall be coded
as specified in Table 27.
Table 27 - GENERATE AC Cryptogram Information Data
Cryptogram Information Data
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - ARQC
1 1 - - - - - - RFU
- - X X - - - - Payment System-specific cryptogram
- - - - 0 - - - No advice required
- - - - 1 - - - Advice required
* Bit 4=1 is not supported by D-PAS
application
- - - - - X X X Reason/advice code

Cryptogram Information Data
- - - - - 0 0 0 No information given
- - - - - 0 0 1 Service not allowed
- - - - - 0 1 0 PIN Try limit exceeded
- - - - - 0 1 1 Issuer authentication failed
- - - - - 1 X X Other values RFU

returned in response to the command. The resulting application state is also shown. Note that
ARQC is only returned in GENERATE AC1 and not in GENERATE AC2.
Table 28 - GENERATE AC Status Words and Application Final State
Resultant
SW1 SW2 State Value
'90 00' ONLINE Command completed successfully (ARQC returned during

GENERATE AC1)
'90 00' SCRIPT Command completed successfully (TC/AAC returned during
GENERATE AC1/2)
'67 00' SELECTED Wrong CDOL data length, no further indication

Figure 7 - GENERATE AC Flow Diagram (Start)
GENERATE AC
command
received
Yes
S1
SW12 STATE P1P2

No
‘6A86’ (SELECTED) OK?
Yes
SW12 STATE Lc
No
‘6700' (SELECTED) OK?
Yes
Yes 1st GEN AC? No Process CDOL2
S2
Process CDOL1
S3
Auth. Resp. Code

S4
= Y3 or Z3?
No
PTH
(onlline auth. Completed) Yes
(unable to go online)
Clear all PTH bits Set ‘Unable to go online

B1b1, B1b2, B1b3, B1b4, last transaction’ bit in
B1b5, and B1b6 PTH [B1b6=1]
Set ‘Unable to
Issuer. Auth. Data go online last
present? transaction’ bit
No of CVR B4b8(1)
Yes
ARC = Y3?
And Yes
No Authen Authen No P1 b87 = 01?
Data Data
present ARQC requested by
terminal in 1st GenAC
AAC Yes ?
Issuer Issuer
Authentication Authentication
not performed No
performed
AAC requested
CAC-
CRM
Online
TC requested

Figure 8 - GENERATE AC Flow Diagram (AAC)

Figure 9 - GENERATE AC Flow Diagram (PTH Processing)
PTH
S8
PTC = 0?
Yes
No
PIN Try Limit
exceeded
CVR B5b6(1)
Issuer Auth. Failed?

Update CVR B3b1-4 PTH B1b3 = 1? Yes
with PTC low order
nibble
Set ‘Issuer Auth. Failed’
No bit in CVR B4b6(1)
Update CVR with Script

counter low order nibble
CVR B3b5-8(ScriptCounter)
Script Received?
Yes
PTH B1b2 = 1?
Set ‘Unable to go online Set ‘Script

last transaction’ bit in Yes Unable to go online last
transaction? Received’ bit in
CVR B4b8(1) CVR B4b5(1)
PTH B1b6=1? No
No
Script Failed?
PTH B1b1 = 1? Yes
Go online next
Set ‘PTH forced online’
Yes transaction?
bit in CVR B4b3(1)
PTH B1b5=1?
Set ‘Script
No Failed’ bit in
No CVR B4b4(1)
Set ‘Issuer Auth. Not Issuer Auth. Not CAC

performed’ bit in CVR Yes performed?
B4b7(1) PTH B1b4 = 1?
No Card Action Code

processing

Figure 10 - GENERATE AC Flow Diagram (CAC)
S13
CAC
Card Action Codes
Processing
AAC
Yes Application Blocked?
NO
ARQC TC
Compare all bits in CVR B4 and Compare all bits in CVR B4 and
AC requested in P1?
B5 with “CAC -Decline” B5 with “CAC -Decline”
AAC
Match?
Match?
No Yes Yes
No
ARQC AAC CAC- AAC

Online

Figure 11 - GENERATE AC Flow Diagram (ARQC)

Figure 12 - GENERATE AC Flow Diagram (CAC-Online)

Figure 13 - GENERATE AC Flow Diagram (NCOT inc)
Update temp
NCOT [volatile)
inc NCOT counter
S11
NCOT counts ONLY

No txns in unrecognised
currency?
PRU b1 = 1b?
Yes
Currency
NCOT + 1 > ‘FF’? No
recognised?
Yes
Yes
Set NCOT to ‘FF’ No
Increment temp
(volatile) NCOT
RETURN
continue Card Risk

Management

Figure 14 - GENERATE AC Flow Diagram (CRM)

Figure 15 - GENERATE AC Flow Diagram (TC1)
TC1 Generating GENAC1

Transaction Certificate
STATE
(SCRIPT)
Set CID to TC
CID b87(01)
Logging supported ?
ACO B1b3 = 1?
Set CVR to
TC returned in GENAC1 and S5
Yes
GENAC2 not requested No
CVR B1b8-5(1001)
Log Txn
S11
Non-Volatile COA = temp COA
Include Issuer
Discretionary data in
Profile-specific NCOT IAD?
indicated in PRU byte? ACO B2b6 =1 ?
Yes
No
Profile-specific Non- Yes No

Global Non-Volatile S6
Volatile NCOT =
NCOT = temp NCOT temp NCOT
Add Issuer Discretionary
data to IAD
CDA requested and No

supported by card?
GENAC
Yes
Set ‘CDA returned in Generate Application

GENAC1’ bit Cryptogram
CVR B2b7(1)

Figure 16 - GENERATE AC Flow Diagram (Authen Data Present)

Figure 17 - GENERATE AC Flow Diagram (No Authen Data)
Issuer Authentication not performed
No Authen
Data
Set ‘Issuer Authentication not

Performed’ bit
PTH B1b4 = 1
Partial grade authorization

response accepted? No
ACO B1b5=1b?
Yes
Reset profile-specified COTN

Reset counters during partial
counter and global COA Yes
grade transaction?
counter
ACO B1b4 = 1b?
No
Reset Script counter in TC requested? AAC

No
PTH Byte 2 P1 b87 = 01b ?
Yes Generate GENAC2

Application Authentication
Cryptogram
TC2
Generate GENAC2
Transaction Certificate

Figure 18 - GENERATE AC Flow Diagram (TC2)

Figure 19 - GENERATE AC Flow Diagram (GENAC)
Generate Application
GENAC Cryptogram
S9
Include only CVR in
cryptogram input data? Compute hash
No
ACO B2b7 =1 ? result
Yes
Add all Issuer

application data to Add CVR to cryptogram Build ICC
cryptogram input data input data Dynamic Data
S7
Compute hash
Generate ARQC or TC
on Dynamic
Aplication Data
to be signed
Yes
P1 specifies
CDA? Generate RSA
Signature
No
Build GENAC Build GENAC

response response
SW12 SW12
’9000' ’9000'

6.4.6 NOTES
S1. APDU checking
The application shall check the following:
GENERATE AC1
• Parameters P1 b87 = 00b or 01b or 10b and P2 = ‘00’ otherwise status code ‘6A86’ is
returned.
• Length Lc <= 33 and Lc = CDOL1 length otherwise status code ‘6700’ is returned.
GENERATE AC2
• Parameters P1 b87 = 00b or 01b and P2 = ‘00’ otherwise status code ‘6A86’ is
returned.
• Length Lc <= 19 and Lc = CDOL2 length otherwise status code ‘6700’ is returned.
S2. CDOL1 and CDOL2 processing
The data sent by the Terminal in the APDU command contains the data elements which were
requested in CDOL1 and CDOL2. The D-PAS application shall extract CDOL1 data specified in
Table 93 and CDOL2 data specified in Table 94.
S3. Online Authorization Complete

The D-PAS application checks whether the Online Authorization was complete. Refer to
section 4.12.1 for a high level description of this process.
S4. Online Authorization Not Complete – Unable to go online

The D-PAS application checks whether the Online Authorization was not complete. Refer to
Section 4.12.2 for a high level description of this process.
S5. Transaction Logging

The data defined in the Transaction Log Format (tag 9F4F) is logged in the Log File specified
by the Log Entry Data Element (tag 9F4D). Transaction Logging is covered in Section 4.13.
S6. Build Issuer Application Data

During this process the D-PAS application builds the Issuer Application data object. Refer to
the Data Dictionary for more detail about IAD and IADOL.
S7. Generate Application Cryptogram

The Application Cryptogram is generated as described in section 8.1.3.
S8. Previous Transaction Process

Prior to performing Card Risk Management the D-PAS application shall update the CVR with
the values stored in the PTH. This figure also shows the updating of the CVR to reflect the
state of the PTC and Script Counter.
S9. Generate Application Cryptogram

The CDA signature is computed as described in [EMV 4.2-2] Section 6.6.

S10. Velocity Checking and Currency Conversion

Currency conversion and velocity checking is performed. Refer to section 4.11.1 for a high
level description of this process and for a complete Currency Conversion example refer to the
Currency Conversion Code data object in Data dictionary.
S11. Profile Resource Usage (PRU) Processing

During the definition / personalization of a transaction profile, the issuer must choose
between profile-specific resources or the global resource defined in default profile ‘0’. The
profile-specific resources allocated for a given profile are coded into a ‘Profile Resource Usage’
bitmap (PRU) stored in the ‘profile’ object. If a PRU bit is not set, this means that the ‘global’
resource shall be used in this transaction profile. (Note: If Profile ‘0’ is being used, all
resources are by default ‘global’). Pre-CRM incrementation of counters is always performed
with temporary values stored in RAM. Actual values of counters (stored in EEPROM) are only
affected when the transaction has been completed. Refer to Appendix C for a full description
of each of the PRU fields.
S12. Limit Checking Example

This example explains how this profile dependent comparison evaluates:
PRU b3-2 = 00b (Global NCOT checked against Global LCOL)
PRU b3-2 = 10b (Global NCOT checked against Profile specific LCOL)
PRU b3-2 = 11b (Profile Specific NCOT checked against Profile specific LCOL)
PRU b3-2 = 01b (Profile Specific NCOT checked against Global LCOL)
S13. CAC Processing

The contents of CVR byte 4 and byte 5 are compared with the CACs for Denial, Default and
Online. Refer to section 4.11 for a high level description of this process.
S14. Issuer Authentication

When the Authorization Response Cryptogram is received in 2nd GENERATE AC command
data the D-PAS application shall verify this cryptogram as specified in section 8.1.4.
S15. CSU Processing

Once Issuer Authentication is successful, the D-PAS application shall take the actions specified
in the CSU.

6.4.7 EXAMPLE
Table 29 - GENERATE AC Command Example
Command GENERATE APPLICATION CRYPTOGRAM 1
Parameters Amount Authorized 9F02: '000000000100'

Amount Other 9F03: '000000000000'
Term. country code 9F1A: '0840'
TVR 95: '0000000000'
Txn. Currency code 5F2A: '0840'
Txn. Date 9A: '090317'
Txn. Type 9C: '00'
Unpredictable Number 9F37: '09B404CC'
Details TC cryptogram requested.
CL INS P1 P2 Lc Data Le
A
'80' 'AE' '40' '00' '1D' '00000000010000000000000008400000000000084009031 00

70009B404CC'

Table 30 - GENERATE AC Response Example
Response GENERATE APPLICATION CRYPTOGRAM (Format 2)
Parameters Format 2 : '77'

Length : '1F'
CID : '9F27 01 80'
ATC : '9F36 02 0001'
ARQC : '9F26 08 60ED6196B265B3FE'
IAD : '9F10 08 0105A02003000000'
Derivation Key Index = '01'
Cryptogram Version Number = '05'
CVR = 'A01C03000000'
'A0' =ARQC generated
'1C' =Off-line Encrypted PIN verification performed
and successful
'03' = PIN Try Counter Value
Details ARQC cryptogram returned.
Data SW1 SW2
'771F9F2701809F360200019F260860ED6196B265B3F '90 00'

E 9F10080105A02003000000'

6.5 GET CHALLENGE

The GET CHALLENGE command is used to obtain an unpredictable number for use in a
security-related procedure, e.g., Offline Enciphered PIN Verification. The challenge shall be
valid only for the next issued command that should be a VERIFY PIN command containing an
encrypted offline PIN.
The GET CHALLENGE command is available in the INITIALIZED and VERIFIED states.
6.5.2 COMMAND APDU

The GET CHALLENGE command is coded as shown in Table 31.
Table 31 - GET CHALLENGE Command
Code Value
CLA '00'
INS '84'
P1 '00'
P2 '00'
Lc Not present
Data Not present
Le ‘00’

The data field of the response message contains an 8-byte unpredictable number.

Table 32 - GET CHALLENGE Status Words and Application Final State
Resultant
SW1 SW2 State Value
'90 00' CHALLENGED Command completed successfully

'6C XX' NO CHANGE Wrong Le field; SW2 encodes the exact number of available data
bytes

Figure 20 - GET CHALLENGE Transaction Flow
GET CHALLENGE
received
STATE= STATE= SW12

No No
INITIALIZED? VERIFIED? ‘6985’
Yes
Yes
SW12
P1P2 OK? No
‘6A86’
Yes
Generate 8 bytes
of unpredictable
numbers
STATE
(CHALLENGED)
SW12
‘9000’
6.5.6 NOTES
None.

6.5.7 EXAMPLE
Table 33 - GET CHALLENGE Command Example
Command GET CHALLENGE
Parameters None
Details None
'00' '84' '00' '00' Not Not present ‘00’

presen
t
Table 34 - GET CHALLENGE Response Example
Response GET CHALLENGE
Parameters None
Details 8 bytes of unpredictable number
Data SW1 SW2
‘4A 83 02 92 2A 20 F2 42’ '90 00'

6.6 GET DATA

The GET DATA command is used to obtain a data object not available in a record within the
current application.
Depending on data objects and the setting of configuration option, a GET PROCESSING
OPTIONS and/or a VERIFY command may be required prior to this command.
Following the GET DATA command, the D-PAS application will always remain in the current
state regardless of the command execution outcome.
6.6.2 COMMAND APDU

The GET DATA command is coded as shown in Table 35.
Table 35 - GET DATA Command
Code Value
CLA '80'
INS 'CA'
P1 Data object tag. See Table 36.
P2
Lc Not present
Data Not Present
Le ‘00’
Table 36 - Tags supported by the GET DATA Command

The supported tags are listed in Table 36.
P1P2 Data Element Length
‘0082’ Application Interchange Profile *profile-specific 2

‘0094’ Application File Locator *profile-specific Var.
‘00C1’ Application Configuration Options 2
‘00C2’ Issuer Life Cycle Data 48
‘00C3’ Currency Conversion Code 1 5
‘00C5’ Card Action Code – Denial *profile-specific 2
‘00C6’ Card Action Code – Default *profile-specific 2
‘00C7’ Card Action Code – Online *profile-specific 2
‘00C8’ Lower Cumulative Offline Amount (LCOA) *profile-specific 6
‘00C9’ Upper Cumulative Offline Amount (UCOA) *profile-specific 6

‘00CA’ Single Transaction Amount (STA) limit *profile-specific 6
‘00CB’ Lower Consecutive Offline Limit (LCOL) *profile-specific 1
‘00CC’ Upper Consecutive Offline Limit (UCOL) *profile-specific 1
‘00CD’ Number of Consecutive Offline Transactions (NCOT) Counter 1
*profile-specific
‘00CE’ Cumulative Offline Amount (COA) Counter *global 6
‘00D0’ Issuer Application Data Object List Var.
‘00D1’ Offline Balance 6
‘00D2’ CRM Country Code 2
‘00D3’ CRM Currency Code 2
‘9F17’ PIN Try Counter 1
‘9F36’ Application Transaction Counter (ATC) 2
‘9F4F’ Log Format Var.
‘DF01’ – ‘DF0A’ Issuer Defined Data Tag (IDDT) 0 –- 9 Var.
‘DF10’ PDOL Check Table – Denial Var.
‘DF11’ PDOL Check Table – Profile Var.
‘DF12’ PDOL Check Table – Online Var.
‘DF20’ – ‘DF2F’ Transaction Profile Objects (0 – 15) 62 each

The data field of the response message contains the TLV of the data object identified by P1P2
of the command. If the tag references the AIP, AFL, or any CRM resources in the tag range
‘C5’-‘CD’, the value returned is the value of this element in the currently selected Transaction
profile object.
Note: ‘*profile-specific’ resources are only available through a GET DATA command received
after the GPO command. Prior to the GPO command, profile-specific resources are not
initialized, and the application must return an error response code of ‘6985’.

Table 37 - GET DATA Status Words and Application Final State
SW1 SW2 Resultant State Value
'90 00' NO CHANGE Command completed successfully

'69 82' NO CHANGE Security status not satisfied
’69 85’ NO CHANGE Conditions of use not satisfied (or reference data not initialized)
‘6A 88’ NO CHANGE Reference data not found

'6C XX' NO CHANGE Wrong Le field; SW2 encodes the exact number of available data
bytes
Figure 21 - GET DATA Transaction Flow Diagram
6.6.6 NOTES
S0
Check if GET DATA is only allowed after GPO.
S1
Check if P1P2 is an accepted tag; otherwise, error status words (‘6A88’) are returned. If
length indicated in Le is not equal to Data Object length, then ‘6CXX’ is returned, with ‘XX’
containing the length of the Data Object. A subsequent GET DATA with exact length of ‘XX’ in
Le will then be expected.
S2
Check if the Offline Balance Data Object or Counter Value/Limit has been requested for the
following Data Elements:
Tag Data Element
00C8 Lower Cumulative Offline Amount (LCOA)
00C9 Upper Cumulative Offline Amount (UCOA)
00CA Single Transaction Amount (STA) limit
00CB Lower Consecutive Offline Limit (LCOL)
00CC Upper Consecutive Offline Limit (UCOL)
00CD Number of Consecutive Offline Transactions (NCOT) Counter
00CE Cumulative Offline Amount (COA) Counter
00D1 Offline Balance
S3
If retrieval of the balance is allowed, the application computes the offline balance. Otherwise
the command is rejected (‘6985’).
S4
The offline balance is calculated as follows:
Offline Balance = UCOA – COA
If an overflow occurs, the application returns zero value for the balance.
S5
If a GET DATA command is received before the GPO command (i.e., STATE != INITIALIZED or
SCRIPT), and a ‘profile-specific’ resource with tag in the range ‘C5’ – ‘CD’ is requested, the
card returns an error response of ‘6985’ indicating “Conditions of use not satisfied” (Profile
resources have not been initialized.)
6.6.7 EXAMPLE
Table 38 - GET DATA Command Example
Command GET DATA
Parameters ‘9F17’
Details None
'80' 'CA' '9F' '17' Not present Not present '00'
Table 39 - GET DATA Response Example
Response GET DATA
Parameters Retrieve PTC
Details None
Data SW1 SW2
9F170103 '90 00'
6.7 GET PROCESSING OPTIONS

The GET PROCESSING OPTIONS command is used to inform the ICC that the processing of a
new transaction is beginning.
This command ensures that the following are performed:
begun.

(PDOL-Profile check). Note: Profile-specific CRM values shall be used in all
subsequent processing, including following PDOL check.

• Ensure that the D-PAS application provides to the terminal the proper AIP and a
list of files that contain the D-PAS chip card application data, to be used in
processing the transaction (AFL). The AIP and AFL may be transaction profile-
specific.
• The D-PAS application shall also increment the ATC, and reset the CVR (Card
Verification Results). The application is now in an ‘INITIALIZED’ state.
6.7.2 COMMAND APDU

The GET PROCESSING OPTIONS command is coded as shown in Table 40.
Table 40 - GET PROCESSING OPTIONS Command
Code Value
CLA '80'
INS 'A8'
P1 '00'
P2 '00'
Lc Var.
Data Tag '83' || Length || Concatenation of the BER-TLV value of the data elements
specified in Processing Options Data Object List (PDOL)
Le '00'
When no PDOL elements are defined, the command data shall be set to '8300'.

The data field returned in the response message shall be coded according to EMV format 2.
Format 2
A constructed data object with BER-TLV tag equal to ‘77’. The value field shall consist of
several BER-TLV coded objects, but shall always include the mandatory data specified in Table
41. If any of these mandatory data elements are missing, the terminal shall terminate the
transaction.
Table 41 - Mandatory GET PROCESSING OPTIONS Response Message Data Field
Application Interchange Profile (AIP) 82 Mandatory

Application File Locator (AFL) 94 Mandatory

Table 42 - GET PROCESSING OPTIONS Status Words and Application Final State
Resultant
SW1 SW2 State Value
'90 00' INITIALIZED Command completed successfully

Figure 22 - GET PROCESSING OPTIONS Flow Diagram
6.7.6 NOTES
S0
The application shall check the following:
• Parameters P1P2 are both ‘00’ otherwise status code ‘6A86’ is returned.
• Lc is correct otherwise status code ‘6700’ is returned.
S1
If the ATC Limit or the Encrypted PIN Cryptography Failure Limit counters of the D-PAS
application is exceeded, the application is disabled and error response status words SW1 SW2
'6985' (Conditions of use not satisfied) are returned.
S2
(or clearing) byte 2, bit 4 of the global ACO element. If this bit is set, any previously defined
PDOL-checks (Decline, Profile, and Online) are executed. If this bit is not set, the card shall
not perform any PDOL-check processing (functionality is disabled).
S3
The PDOL Processing Mechanism description and an implementation example may be found in
Appendix C.
6.7.7 EXAMPLE
Table 43 - GET PROCESSING OPTIONS Command Example
Command GET PROCESSING OPTIONS
Parameters Command template: '83'

Length: '10'
Amount authorized 9F02: '000000009999'
Terminal Country Code 9F1A: '0840'
Transaction Currency code 5F2A: '0840'
Transaction Date 9A: '080607'
Terminal Type 9F35: '25'
first two bytes of Terminal Capabilities 9F40: '0000'
Details • PDOL content ('9F02 06 9F1A 02 5F2A 02 9A 03 9F35 01 9F40 02') sent to
ICC.
'80' 'A8' '00' '00' '12' '831000000000999908400840080607250000' '00'
Table 44 - GET PROCESSING OPTIONS Response Example
Response GET PROCESSING OPTIONS
Parameters AIP 82:

7900 SDA supported
DDA supported
Cardholder verification supported
Terminal Risk Management to be performed
CDA supported
AFL 94:
08010100 (SFI=1, First Rec = 1, Last Rec = 1, Data Auth Recs = 0)
Details AIP and AFL returned
Data SW1 SW2
'771682027900941008010100100101001002020110030300' '90 00'
6.8 INTERNAL AUTHENTICATE

The INTERNAL AUTHENTICATE command triggers the generation of the Signed Dynamic
Application Data using ICC data and data sent from the terminal, as specified in the DDOL list.
The ICC signs this data with the ICC Private Key.
The purpose of this authentication is to prove that the card is genuine.
6.8.2 COMMAND APDU

The INTERNAL AUTHENTICATE command is coded as shown in Table 45.
Table 45 - INTERNAL AUTHENTICATE Command
Code Value
CLA '00'
INS '88'
P1 '00'
P2 '00'
Lc Length of authentication-related data
Data Authentication-related data - Concatenation of the BER-TLV value of the data
elements specified in DDOL
Le '00'
It is mandatory that the DDOL contains at least the 4 byte unpredictable number BER-TLV tag
‘9F37’ generated by the Terminal.

The data object returned shall be in Format 2.
Table 46 - INTERNAL AUTHENTICATE Response Message Data Field
Signed Dynamic Application Data 9F4B Mandatory
This format consists of a constructed data object with BER-TLV tag equal to ‘77’. The value
field shall consist of one or more BER-TLV coded objects, but shall always include the
mandatory data specified in Table 46. If this mandatory data element is missing the terminal
shall terminate the transaction.
Note: The length of the Signed Dynamic Application Data is the same as the Length of the
ICC Public Key.

Table 47 - INTERNAL AUTHENTICATE Status Words and Application Final State
Resultant
SW1 SW2 State Value
'90 00' INITIALIZED Command completed successfully

Figure 23 - INTERNAL AUTHENTICATE Flow Diagram
INTERNAL
AUTHENTICATE
command received
STATE SW12
P1P2 OK? No
(SELECTED) ‘6A86’
Yes
STATE SW12
Lc OK? No
(SELECTED) ‘6700'
Yes
S0
First Internal STATE SW12
No
Auth.? (SELECTED) ‘6985'
S1 Yes
Process DDOL
S2
Generate Hash of the Dynamic

Application Data
S3
Generate Signed Dynamic

Application Data using the ICC
Private Key
Set ‘DDA returned’ bit

CVR B2b8(1)
STATE
(INITIALIZED)
SW12
‘9000'
6.8.6 NOTES
S0
The application shall ensure that only one INTERNAL AUTHENTICATE command is issued for
each value of the ATC, otherwise status code ‘6985’ is returned.
S1
The D-PAS application shall extract the data specified by the DDOL. It is mandatory that the
DDOL contains at least the 4 byte unpredictable number BER-TLV tag ‘9F37’ generated by the
Terminal.
S2
The generation of data shown in Table 48 is input to the Hash Algorithm.
Table 48 - Input Data to Hash Algorithm
Field Name Length Description Format
Signed Data Format 1 Hex value '05' b
Hash Algorithm Indicator 1 Identifies the hash algorithm b

used to produce the Hash Result
ICC Dynamic Data Length 1 Identifies the length of the ICC b
Dynamic Data (Ldd) in bytes
ICC Dynamic Data Ldd Dynamic data generated by -
and/or stored in the ICC
(0<=Ldd<=(NICC-
25))
Pad Pattern NICC - Ldd - 25 (NICC – Ldd - 25) padding bytes B
of value 'BB'
Terminal Dynamic Data Var. Concatenation of the data -
elements specified by the DDOL
S3
The ICC generates a signature on the data specified in Table 49 using the ICC private key.
The result of this process is called the Signed Dynamic Application Data is specified in [EMV
4.2-2] Section 6.5.1.
Table 49 - Data to Be Signed by ICC Private Key
Field Name Length Description Format
Recovered Data Header 1 Hex value '6A' b
Hash Result 20 Hash of the Dynamic Application b

Data and related information
Recovery Data Trailer 1 Hex value 'BC' b
6.8.7 EXAMPLE
Table 50 - INTERNAL AUTHENTICATE Command Example
Command INTERNAL AUTHENTICATE
Parameters Unpredictable number 9F37: 'A6150EDE'
Details DDOL content: 9F3704 (4 byte unpredictable number)
'00' '88' '00' '00' '04' 'A6150EDE' '00'
Table 51 - INTERNAL AUTHENTICATE Format 2 Response Example
Response INTERNAL AUTHENTICATE (format 2)
Parameters Signed Dynamic Application Data 9F48
Details Signed Dynamic Application Data returned
Data SW1
SW2
'7781849F4B81808443550C33AAB340F2A2AFF632FFA15D4A70E0F4514D831ACD3223C '90 00'

8C1EDFFDD45F74927BCAFA1439BCFCABF3A9EAADEBB8D6B837186A872595128286D5
BE315E2EB33926863C757BC1922FE33A8F5F486CBEC0F491F0CD23183E62335DCB8B6A
22D75B9FD7B285E57558714A1083C581E1F82D5942818CFD48BDE4E6362FA29'
6.9 PIN CHANGE/UNBLOCK

The PIN CHANGE/UNBLOCK command is a script command. Its purpose is to provide the
issuer the capability either to unblock the PIN or to simultaneously change and unblock the
reference PIN. Upon successful completion of the PIN CHANGE/UNBLOCK command, the card
shall perform the following functions:
• The value of the PIN Try Counter shall be reset to the value of the PIN Try Limit.
• If requested, the value of the reference PIN shall be set to the new PIN value.
6.9.2 COMMAND APDU

The PIN CHANGE/UNBLOCK command is coded as shown in Table 52.
Table 52 - PIN CHANGE/UNBLOCK Command
Code Value
CLA '84'
INS '24'
P1 '00'
P2 '00' if data contains only a MAC (PIN UNBLOCK)
‘02’ if data contains enciphered PIN and MAC (PIN Change)
Lc '0x08' if P2 = '00'
'0x10' if P2 = '02'
Data Enciphered PIN data component, if present, and MAC data component.
Le Not Present
If P2 is ‘00’, the reference PIN is unblocked and the PIN Try Counter is reset to the PIN Try
Limit. The existing PIN value is retained as the PIN data component is not present.
If P2 is ’02’, this indicates an 8-byte PIN data component is present and it is enciphered. The
plaintext PIN data component format is defined in section 6.14.2. The 8-byte plaintext PIN
block is enciphered with the method as defined in section 7.5.
If the PIN data component is present, the encrypted PIN block is used in MAC generation. The
command data, when P2 is ‘02’, is thus a concatenation of the new enciphered PIN value and
MAC.


Table 53 - PIN CHANGE/UNBLOCK Status Words and Application Final State
Resultant
SW1 SW2 State Value

’69 82’ SELECTED Invalid decrypted PIN block format [Security Status not satisfied]
Figure 24 - PIN CHANGE/UNBLOCK Transaction Flow Diagram.
PIN CHANGE/UNBLOCK
received
Set Script
Received in PTH
Set Script Failed

bit in PTH S3
STATE= STATE SW12

No
SCRIPT? (SELECTED) ‘6985’
Yes
STATE SW12
P1P2 OK? No
(SELECTED) ‘6A86’
Yes
P2=’02' and P2=’00' and

Command data No Command data STATE SW12
No
length =‘10’? length = ‘8’? (SELECTED) ‘6700’
Yes
Yes
Lifetime MAC Disable

Yes
limit reached? Application
No
Failed MAC limit OR

Session MAC limit Yes STATE SW12
reached? (SELECTED) ‘6985’
No S0
Increment Session
Failed MAC limit OR
MAC, Failed MAC STATE SW12
Session MAC limit Yes
and Lifetime MAC (SELECTED) ‘6988'
reached?
Security Counters
No
Is MAC valid? No
SW12
S1 ‘6982’
Yes No
Valid PIN STATE
format ? (SELECTED)
Decrypt and Decrement Failed
P2=’00'? No Update PIN
MAC counter,
Increment Script
S2 Yes counter in PTH
No Yes
S3
Clear ‘Script failed’
Set PIN Try bit in PTH
Update
Yes Counter = PIN Try
successful?
Limit
SW12
‘9000’
6.9.6 NOTES
S0
The Session MAC, Failed MAC and Lifetime MAC counters are incremented. The Failed MAC
S1
S2
Decryption is the reverse process as defined in section 7.5.
S3
6.9.7 EXAMPLE – PIN UNBLOCK
Table 54 - PIN UNBLOCK Command Example
Command PIN CHANGE/UNBLOCK
Parameters None
Details • AC is '1234 1234 1234 1234' and this is the 3rd script command in the session
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1236’ (AC+2);
o D1 = ‘8424000008123412’
o D2 = ‘3412341234123680’
The output blocks are thus:
o O1 = ‘C1EDB979ABEDB744’
o O2 = ‘52B08FD0ABE6F37F’
o O3 = ‘30476E27BB00037D’
o O4 = ‘5EF936F6BD07A709’
• The MAC is thus O4 = ‘5EF936F6BD07A709’
'84' '24' '00' '00' '08' '5EF936F6BD07A709’ Not present
Table 55 - PIN UNBLOCK Response Example
Response PIN CHANGE/UNBLOCK
Parameters None
Details PIN is unblocked.
Data SW1 SW2
Not present '90 00'
6.9.8 EXAMPLE – PIN CHANGE
Table 56 - PIN CHANGE Command Example
Command PIN CHANGE/UNBLOCK
Parameters New PIN value
Details • AC is '1234 1234 1234 1234' and this is the 3rd script command in the session
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
• New PIN value is ‘2712 3456 7FFF FFFF’ and no padding necessary.
• Encrypted PIN value is thus: ‘37521B05147C8C6E’
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1236’ (AC+2);
o Encrypted PIN value;
o D1 = ‘8424000218123412’
o D2 = ‘3412341234123637’
o D3 = ‘521B05147C8C6E80’
• The corresponding output blocks are:
o O1 = ‘1B247C7F2CA0BFA3’
o O2 = ‘048B2345CF41C6E3’
o O3 = ‘D76BB0ABC071209B’
o O4 = ‘69AF45A5341EBA25’
o O5 = ‘674FDBC79D60341F’
• MAC value is thus O6 = ‘674FDBC79D60341F’
'84' '24' '00' '02' '10' ‘37521B05147C8C6E674FDBC79D60341F’ Not present
Table 57 - PIN CHANGE Response Example
Response PIN CHANGE/UNBLOCK
Parameters None
Details PIN is changed and unblocked.
Data SW1 SW2
Not present '90 00'
6.10 PUT DATA

The PUT DATA command is an issuer script command that writes new values into specific
Primitive Data Objects.
This command is only available in the SCRIPT state and may be transmitted with or without
Secure Messaging for Integrity. Secure Messaging is required for all data elements except the
Issuer Defined Data Tags for which the requirement for Secure Messaging is specifically
omitted at personalization time.
6.10.2 COMMAND APDU

The PUT DATA command is coded as shown in Table 58. Refer to Table 59 for a list of the
supported Primitive Data Objects.
Table 58 - PUT DATA Command
Code Value
CLA '84' or ‘80’

INS 'DA'
P1 Data object tag. See Table 59
P2
Lc Var.
Data Data Object value and optional MAC
Le Not Present
The following Data Objects may be accessed using the PUT DATA command:
Table 59 - Supported Data Objects in PUT DATA Command
‘0082’ Application Interchange Profile *profile-specified 2

‘0094’ Application File Locator *profile-specified Var.
‘00C1’ Application Configuration Options 2
‘00C5’ Card Action Code – Denial *profile-specified 2
‘00C6’ Card Action Code – Default *profile-specified 2
‘00C7’ Card Action Code – Online *profile-specified 2
‘00C8’ Lower Cumulative Offline Amount (LCOA) *profile-specified 6
‘00C9’ Upper Cumulative Offline Amount (UCOA) *profile-specified 6
‘00CA’ Single Transaction Amount (STA) limit *profile-specified 6
‘00CB’ Lower Consecutive Offline Limit (LCOL) *profile-specified 1
‘00CC’ Upper Consecutive Offline Limit (UCOL) *profile-specified 1
‘00D0’ Issuer Application Data Object List Var.
‘00D2’ CRM Country Code 2
‘00D3’ CRM Currency Code 2
‘DF10’ PDOL Check Table – Denial Var.
‘DF11’ PDOL Check Table – Profile Var.
‘DF12’ PDOL Check Table – Online Var.
‘DF20’ – ‘DF2F’ Transaction Profile Objects (0 – 15) 62 bytes
each
* These CRM resources may be defined as being ‘Profile-specific’ or ‘Global’. If a Global
resource is being used by the currently selected transaction profile, the Global resource (in
profile 0) shall be modified. If a Profile-specific resource is being used by the currently
selected profile, the profile-specific resource will be updated, and the ‘Global’ resource will
remain unchanged… Note: see Appendix C, section 1.


Table 60 - PUT DATA Status Words and Application Final State
Resultant
SW1 SW2 State Value

’65 81’ SELECTED Memory Failure
'67 00' SELECTED Wrong length of tagged value. (Lc != length of tag)
'69 82' SELECTED Security status not satisfied
'69 88' SELECTED Incorrect secure messaging data objects
'6A 88' SELECTED Referenced data not found
Figure 25 - PUT DATA Transaction Flow Diagram (part 1)
Figure 26 - PUT DATA Transaction Flow Diagram (part 2)
6.10.6 NOTES
S0
If the application is not in the SCRIPT state, the command is rejected (SW1-SW2 = ‘6985’)
and the state is set to SELECTED.
S1
If the tag in P1P2 is not in a valid tag for this command, the command is rejected (SW1-SW2
= ‘6A86’) and the state is set to SELECTED.
S2
If the lifetime MAC limit has been reached, the application is permanently disabled and the
command is rejected (SW1-SW2 = ‘6985’).
S3
If the command CLA byte of the command is not '84' for a tag not belonging to IDDT tags,
the command is rejected (SW1-SW2 = ‘6985’) and the state is set to SELECTED.
S4
The Failed MAC and Lifetime MAC counters are incremented. The Failed MAC counter is
decremented when the MAC is correctly verified.
S5
S6
If the MAC is invalid, the Script Failed bit is set in PTH and the command is rejected (SW1-
SW2 = ‘6988’) and the state is set to SELECTED.
S7
If the tag data value is successfully updated, the command is completed. (SW1-SW2 =
‘9000’). If the tag data value is not successfully updated the Script Failed bit is set in PTH and
the command is rejected (SW1-SW2 = ‘6581').
S8
If the tag is an IDDT tag and the application tag size is '00' (an un-initialized tag) then the
command is rejected (SW1-SW2 = ‘6A88’) and the state is set to SELECTED.
S9
If the PUT DATA access condition for the IDDT tag indicates the need for a prior successful
offline PIN verification and if prior the offline PIN verification was unsuccessful, then the
command is rejected (SW1-SW2 = ‘6982’) and the state is set to SELECTED.
S10
If the PUT DATA access condition for the IDDT tag indicates the need for secure messaging
(for integrity) then the application proceeds to verify the MAC security counters. If secure
messaging is not required, then the MAC counter verification step is bypassed and proceeds
onto the next step to update the IDDT value.
S11
If the lifetime MAC limit has been reached, the application is permanently disabled and the
command is rejected (SW1-SW2 = ‘6985’).
S12
If the Failed MAC limit or session MAC limit has been reached, the command is rejected (SW1-
SW2 = ‘6985’) and the state is set to SELECTED.
S13
The Failed MAC and Lifetime MAC counters are incremented. The Failed MAC counter is
decremented when the MAC is correctly verified.
S14
The command MAC is verified as specified in section 7.3. If the MAC is invalid, the Script
Failed bit is set in PTH and the command is rejected (SW1-SW2 = ‘6988’) and the state is set
to SELECTED.
S15
If the tag data value is successfully updated, the command is completed. (SW1-SW2 =
‘9000’). If the tag data value is not successfully updated the Script Failed bit is set in PTH and
the command is rejected (SW1-SW2 = ‘6581').
S16
6.10.7 EXAMPLE
Table 61 - PUT DATA Command Example
Command PUT DATA
Parameters IADOL Tag (‘D0’)

IADOL new value = STA Tag-Len || IDDT1 Tag-Len
Details • AC is '1234 1234 1234 1234' and this is the 2nd script command in the
session
from RL = ‘1234 F034 1234 1234’ and RR = ‘1234 0F34 1234 1234’
o Command header = ‘84DA00D00D’;
o ATC = ‘1234’;
o R = ‘1234 1234 1234 1235’ (AC+1);
o IADOL (‘D0’) to be updated = ‘CA06DF0104’;
o D1 = ‘84DA00D00D123412’
o D2 = ‘34123412341235CA’
o D3 = ‘06DF010480000000’
o O1 = ‘C7D8B5E710248FA8’
o O2 = ‘856879D8D02D6511’
o O3 = ‘7CC33AEB83A0DAC8’
o O4 = ‘43318679FE74DE52’
o O5 = ‘B0FFFCE67C9E63B4’
• The MAC is thus O4 = ‘B0FFFCE67C9E63B4’
'84' 'DA' '00' 'D0' '0D' ' CA06DF0104B0FFFCE67C9E63B4’ Not present
Table 62 - PUT DATA Response Example
Response PUT DATA
Parameters None
Details No response data
Data SW1 SW2
Not present '90 00'
6.11 READ RECORD

The READ RECORD command is used to retrieve a group of data elements constructed in the
format of files and records on the ICC.
The AFL indicates to the terminal those records that may be read out from the ICC.
Depending on the setting of configuration option in ACO, a GET PROCESSING OPTIONS may
be required prior to this command.
This READ RECORD command always remains in the current state regardless of execution
outcome.
6.11.2 COMMAND APDU

The READ RECORD command is coded as shown in Table 63.
Table 63 - READ RECORD Command
Code Value
CLA '00'
INS 'B2'
P1 Record Number
P2 Reference control parameter (see Table 64)
Lc Not present
Data Not present
Le ‘00’
Table 64 - READ RECORD Command Reference Control Parameter

Table 64 defines the reference control parameter of the command message:
Bit Bit Bit Bit Bit Bit Bit Bit Meaning

8 7 6 5 4 3 2 1
x x x x x SFI
1 0 0 P1 is a record number

The data field of the response message of any successful READ RECORD command contains
the record read. For SFIs in the range 1-10, the record is a BER-TLV constructed data object
coded as shown in Figure 27.
Figure 27 - READ RECORD Response Message Data Field
'70' Length Record Template

Table 65 - READ RECORD Status Words and Application Final State
'90 00' NO CHANGE Command completed successfully

'6C XX' NO CHANGE Wrong length, ‘Read Record’ command with proper Le of ‘XX’
expected…
'69 85' NO CHANGE Conditions of use not satisfied
'6A 82' NO CHANGE File not found
'6A 83' NO CHANGE Record not found
‘6A 86’ NO CHANGE Incorrect parameters P1-P2
The response message to READ RECORD for SFIs in the range 11-30 is outside the scope of
this specification.
Figure 28 - READ RECORD Transaction Flow Diagram
READ RECORD
recieived
S0
ACO B2b2 = 1?
SW12
Yes AND STATE =
‘6985'
SELECTED?
No
S1
SW12 P2=04? SW12

P2 Bad record
‘6A86' P1 valid record? ‘6A82'
Yes
SW12
Yes Wrong length?
‘6CXX'
No
S2 S3
Which type of SW12

emv other
record? ‘6A86'
Out of scope
payment
S4 S7
SFI = supported SW12 SFI = supported

No No
file? ‘6A82' file?
Yes
Yes
S5 S8
SW12
Record found? No No Record found?
‘6A83'
Yes
S6
SW12
Record in AFL? No
‘6985'
Yes Yes
SW12
response = record ‘9000'
6.11.6 NOTES
S0
The application checks if READ RECORD is allowed to only run after GET PROCESSING
OPTIONS.
S1
The application checks that P1 <> ‘00’ and (P2 AND ‘07’) = ‘04’. Otherwise the command is
rejected (‘6A86’).
S2
Check if the file to read is an EMV file, a payment system specific file, or another file:
• If the SFI is in the range 1 to 10, then the file is an EMV file.
• If the SFI is in the range 11 to 20, then the file is a payment system specific
file.
• If the SFI is not in the range 1 to 20, then the file is neither an EMV file nor a
payment system specific file.
S3
If the file is neither an EMV file nor a payment system specific file, it is not allowed and the
command is rejected (‘6A86’).
S4
If the file is an EMV file, the application verifies that the SFI corresponds to a supported
record file. If the record file is not supported, the command is rejected (‘6A82”).
S5
The application verifies that there is a record corresponding to the record number; otherwise
the command is rejected (‘6A83’).
S6
The application checks that the record is referenced in the AFL. If the record is not referenced
in AFL, the command is rejected (‘6985’). If the record is referenced in AFL, it is sent in the
response.
S7
If the file is a payment-system specific file, the application verifies that the SFI corresponds to
a supported record file.
The only payment-system specific file that must be supported by the application is the
Transaction Log, with SFI 11. Other specific files are outside the scope of this specification.
If the file is not supported, the command is rejected (‘6A82’’).
S8
The application verifies that there is a logged record corresponding to the Record Number,
otherwise the command is rejected (‘6A83’).
There is no limit on the number of records that the application may hold.
6.11.7 EXAMPLE
Table 66 - READ RECORD Command Example
Command READ RECORD
Parameters SFI 4 Record 3
Details None
'00' 'B2' '03' '24' Not present Not present ‘00’
Table 67 - READ RECORD Response Example
Response READ RECORD
Parameters CDOL1
Details CDOL1 comprising the Data Object List of ‘9F02’, ‘9F03’, ‘9F1A’, ‘95’, ‘5F2A’, ‘9A’,
‘9C’ and ‘9F37’.
Data SW1 SW2
‘7017 8C15 9F02 069F 0306 '90 00'

9F1A 0295 055F 2A02 9A03
9C01 9F37 04 ‘
6.12 SELECT

A SELECT command is used to select either the payment application or the supported
alternate application.
When the partial AID is used and it matches with more than one application, the application
selected depends on the sequence in which the applications are loaded onto the card.
6.12.2 COMMAND APDU

The SELECT command is coded as shown in Table 68.
Table 68 - SELECT Command
Code Value
CLA '00'
INS 'A4'
P1 ‘04’
P2 ’00’' - First or only occurrence
'02' - Next occurrence
Lc ‘05’-‘10’
Data Partial or Full AID
Le ‘00’

The FCI structure shown in Table 69 is returned in the response message.
Table 69 - SELECT Response Message Data Field
Tag Value Presence
‘6F’ FCI Template M

‘84’ DF Name M
‘A5’ FCI Proprietary Template M
‘50’ Application Label M
‘87’ Application Priority Indicator O
‘5F2D’ Language Preference O
‘9F11’ Issuer Code Table Index O
‘9F12’ Application Preferred Name O
‘9F38’ PDOL O
‘BF0C’ FCI Issuer Discretionary Data O
‘42’ Issuer Identifier Number O
‘5F28’ Issuer Country Code O
‘9F4D’ Log Entry O
‘DF62’ Application Selection Tag O

Table 70 - SELECT Status Words and Application Final State
'90 00' SELECTED Command completed successfully

’62 83’ SELECTED Application Blocked (Warning)
’6A 81’ IDLE Card Blocked
'6A 82' IDLE / SELECTED* Application not found
'6A 86'* IDLE / SELECTED* Incorrect parameters P1-P2
Note: Processing of the ‘Select DF’ command is very often handled by the Card Operating
System, and not the card application. Therefore, the states and error codes specified in table
above, and sequence of events illustrated in following flowchart is only a plausible
representation of how a specific card OS might process the ‘Select’ command. There may
however be differences occurring from one card type to another.
Figure 29 - SELECT FILE Command Transaction Flow Diagram
SELECT received
SW12
Yes Card blocked?
‘6A81’
S0
No
SW12 P1 = ‘04'
No
‘6A86’ P2 = ‘00’ or ‘02’
S1
Yes
Match AID
SW12
No AID matched?
‘6A82’
Yes
SW12 Application
Yes
‘6283’ Blocked?
No
Build FCI
response
SW12
‘9000’
6.12.6 NOTES
S0
If P1 P2 are invalid the application returns '6A 86'.
S1
In the case that an AID has been successfully selected, if the card receives a SELECT
command APDU with P2 = '02' and the same partial AID, as the next immediate command,
the card shall select a different AID matching the partial AID if it exists on the card.
If this process is repeated and there are no further match of the partial AID, the card returns
'6A 82'.
An SW1 SW2 response of '9000' indicates a successful execution of the command.
6.12.7 EXAMPLE
Table 71 - SELECT Command Example
Command SELECT
Parameters ‘A0000001523010’
Details None
'00' 'A4' '04' '00' '07' 'A0000001523010’ ‘00’
Table 72 - SELECT Response Example
Response SELECT
Parameters The FCI defined for the D-PAS Credit application.
Details None
Data SW1 SW2
‘6F178407A0000001523010A50C500A44434920437265646974’ '90 00'
6.13 UPDATE RECORD

The UPDATE RECORD command is an issuer script command that writes new values into
Record EF identified by an SFI.
This command is only available in the SCRIPT state
6.13.2 COMMAND APDU

The UPDATE RECORD command is coded as shown in Table 73.
Table 73 - UPDATE RECORD Command
Code Value
CLA '84'
INS 'DC'
P1 Record Number
P2 Reference Control Parameter
Lc Length of command data
Data Data Object value and MAC
Le Not Present
The Reference Control Parameter specifies the SFI and indicates record number is specified in
P1. It is coded as shown in Table 74.
Table 74 - UPDATE RECORD Command Reference Control Parameter Definition
Bits Value
b8 – b4 SFI
b3 – b1 100 (binary value)


Table 75 - UPDATE RECORD status words and application final state
Resultant
SW1 SW2 State Value

’65 81’ SELECTED Memory Failure
'67 00' SELECTED Wrong length for record data (Lc != Record length)
'69 82' SELECTED Security status not satisfied
'6A 88' SELECTED Referenced data not found
Figure 30 - UPDATE RECORD Transaction Flow Diagram
6.13.6 NOTES
S0
The Session MAC, Failed MAC and Lifetime MAC counters are incremented. The Failed MAC
S1
S2
6.13.7 EXAMPLE
Table 76 - UPDATE RECORD Command Example
Command UPDATE RECORD
Parameters SFI = 2, Record# = 3

Record to be updated with data = "7010 8E0E 0000 0000 0000 0000 4403 4203
1F03"
Details • This is the 2nd script command in the session

• Application cryptogram (AC) = '1234 1234 1234 1234'
• Diversification value R = AC = '1234 1234 1234 1234’
• RL = ‘1234 F034 1234 1234’
• RR = ‘1234 0F34 1234 1234’
• MKSMI = CB45F892BCDA763E F131AE6DE0762634
• Session key SKSMI is thus:
SKSMI = DES3(MKSMI)[ RL] || DES3(MKSMI)[ RR]
SKSMI = ‘7A36C671D15746BE 3F1398136AFD9546’
o Command header = ‘84DC031416’;
o ATC = ‘1234’;
o Unpredictable value R = ‘1234 1234 1234 1235’ (AC+1);
o Record to be updated with the data = ‘70108E0E0000 0000 0000
0000 4403 4203 1F03’;
o D1 = '84DC031416123412'
o D2 = '3412341234123570'
o D3 = '108E0E0000000000'
o D4 = ' 000000440342031F'
o D5 = ' 0380000000000000'
o The output blocks are thus:
o O1 = 'AEC5F04E0F024AB5'
o O2 = 'D3BAD54DC89021A'
o O3 = '5EB870443A982C7'
o O4 = '8C1C61D0EAEAAA9'
o O5 = 'B3DD6C0A8BECD2E'
o O6 = 'C94C5D3F6506CF5'
o O7 = '92C354B8847E467'
o The MAC is thus O7 = ‘92C354B8847E467’
'84' 'DC' '03' 14' '1A' '70108E0E0000000000000000440342031F0392C354B8847E467 Not

' present
Table 77 - UPDATE RECORD Response Example
Response UPDATE RECORD
Parameters None
Details No response data
Data SW1 SW2
Not present '90 00'
6.14 VERIFY

The VERIFY command compares in the ICC the PIN Data sent via the command with the
reference PIN data associated with the application.
The VERIFY command applies when the Cardholder Verification Method (CVM) chosen from
the CVM List is an offline PIN.
The VERIFY command is in accordance to [EMV 4.2-3].
6.14.2 COMMAND APDU

The VERIFY command is coded as shown in Table 78.
Table 78 - VERIFY Command
Code Value
CLA '00'
INS '20'
P1 '00'
P2 ‘80’ – Plaintext PIN
‘88’ – Enciphered PIN
Lc Var.
Data Transaction PIN Data
Le Not Present
The processing of the VERIFY command in the ICC is defined in combination with the CVM
rules.
Command Data length (Lc) varies according to whether the PIN block is enciphered or
plaintext. If P2 specifies ‘Plaintext offline PIN’, Lc must take the value of ‘08’. If P2 specifies
‘Encrypted offline PIN’, Lc will be equal to the Modulus length of ICC PIN encryption key.
The plaintext offline PIN block shall be formatted as follows:
Table 79 - Plaintext Offline PIN Block Format

C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
where:
Name Value
C Control field 4 bit binary number with value of 0010 (Hex '2')
N PIN length 4 bit binary number with permissible values of 0100 to 1100 (Hex
'4' to 'C')
P PIN digit 4 bit binary number with permissible values of 0000 to 1001 (Hex
'0' to '9')
P/F PIN/filler Determined by PIN length
F Filler 4 bit binary number with a value of 1111 (Hex 'F')


'9000' indicates a successful execution of the command.
When for the currently selected application the comparison between the Transaction PIN Data
and the reference PIN data performed by the VERIFY command fails, the ICC shall return SW2
= 'Cx', where 'x' represents the number of retries still possible. When the card returns 'C0',
no more retries are left, and the CVM shall be blocked. Any subsequent VERIFY command
applied in the context of that application shall then fail with SW1 SW2 = '6983'.
Table 80 - VERIFY Status Words and Application Final State
'90 00' VERIFIED Command completed successfully

'63 Cx' INITIALIZED Verification failed, number of retries is x
’69 83’ INITIALIZED Authentication method blocked
'69 85' INITIALIZED Conditions of use not satisfied
’67 00’ INITIALIZED Wrong length of command data
‘6A 86’ INITIALIZED Incorrect P1-P2 parameters
Figure 31 - VERIFY Transaction Flow Diagram 1
VERIFY received
S0
P1 = ‘00'
no
SW12
‘6A86’ yes
no
S1
P2 = ‘80’ or ‘88'
‘80’ ‘88’
S2 S3
Cleartext SW12 encrypted

no no
accepted? ‘6985’ accepted?
yes yes
cleartext encrypted
Figure 32 - VERIFY Transaction Flow Diagram 2
6.14.6 NOTES
S0
P1 = ‘00’, otherwise the command is rejected (SW1-SW2 = ‘6A86’).
S1
If P2 = ‘88’ offline encrypted PIN verification is used. If P2 = ‘80’ offline plaintext PIN
verification is used. For any other value, the command is rejected (‘6A86’).
S2
If P2 = ‘88’, offline encrypted PIN verification is used by the terminal. The application checks
that offline encrypted PIN verification is supported. If not, the command is rejected (‘6985’).
S3
If P2 = ‘80’, offline plaintext PIN verification is used by the terminal. The application checks
that offline plaintext PIN verification is supported. If not, the command is rejected (‘6985’).
S4
If an ICC PIN Encipherment Key is present and the ACO Byte 1 bit 7 is configured, it is
selected. If not present, the ICC Key is selected for use in the subsequent steps.
S5
Check if Lc = selected key length (NICC or NPE), otherwise the command is rejected (‘6700’).
S6
The VERIFY command is rejected (‘6985’) if the immediately previous APDU command was
not a successful GET CHALLENGE command.
S7
Increment the Encrypted PIN Cryptography Failure Counter first. This Counter is decremented
at a later step when PIN decryption is successful.
S8
The encrypted PIN Data is decrypted and unpacked in accordance to [EMV 4.2-2] with the ICC
or the PE Private Key.
S9
The application verifies the format of the decrypted fields, recovered PIN block is valid and the
previously issued challenge bytes are correct.
If the verification fails, PIN verification has failed (‘63Cx’, with x = right nibble of PIN Try
Counter).
S10
The application verifies the input PIN with the Reference PIN.
If the verification fails, PIN verification has failed ( ‘63Cx’, with x = right nibble of PIN Try
Counter).
6.14.7 EXAMPLE
Table 81 - VERIFY Command Example
Command VERIFY
Parameters Reference PIN = ‘1234’

Plaintext
Details None
'00' '20' '00' '80' '08' '241234FFFFFFFF' Not present
Table 82 - VERIFY Response Example
Response VERIFY
Parameters None
Details
Data SW1 SW2
Not present '90 00'
7 ISSUER SCRIPT COMMAND PROCESSING
7.1 SCRIPT COMMANDS

The following Issuer Script Commands are supported:
• APPLICATION BLOCK
• APPLICATION UNBLOCK
• CARD BLOCK
• PIN CHANGE/UNBLOCK
• PUT DATA
• UPDATE RECORD
Script commands are accepted when the card is in a ‘SCRIPT’ state, i.e., after a TC or AAC is
returned in response to a 1st or 2nd GENERATE AC command (tag ‘72’ scripts). No tag ’71’
scripts (executed between 1st and 2nd GENERATE AC commands) are accepted by the card
application. The Issuer Script Command Processing flow is shown in Figure 33.
Figure 33 - Issuer Script Commands Flow Diagram
D-PAS EMV Chip terminal
‘Machine-State’ Issuer Script

‘SCRIPT’ Commands
Issuer Script
received?
Set ‘Issuer Script

received’ bit in PTH
Perform Issuer Scripted

command ‘Machine-State’
‘SCRIPT’
No 9000
Issuer Script Increment Script
failed? counter in PTH Issuer Script (‘72’)
Yes Command specific

response
Set ‘Issuer Script failed’
bit in PTH
Set ‘Machine-
State’ to
‘SELECTED’
7.2 SECURE MESSAGING FORMAT

The secure messaging format supported by D-PAS is Format 2. Format 2 Secure Messaging is
described in [EMV 4.2-2].
7.3 SECURE MESSAGING FOR INTEGRITY (SMI)

The value ‘4’ in the second nibble of the CLA byte of an APDU indicates the APDU data is
protected by secure messaging.
The secure message MAC is used to verify message integrity and to provide Issuer
Authentication. The MAC is the last data element in the APDU data field, and always has a
length of eight bytes.
The MAC is generated using according to the following steps,
1. The following data is concatenated in the order specified to create a block of data (D).
• CLA, INS, P1, P2, Lc,
• ATC ,
• An 8-byte unpredictable value R. For the first issuer script command, R is the
application cryptogram provided by the card in response to the 1st GENERATE
AC command. All of the following issuer script commands generated and sent in
this session use the previous value of R + 1. For example, if R is the application
cryptogram = '1234 1234 1234 1234’, then,
• for the first script in the session, R = '1234 1234 1234 1234’
• for the second script in the session, R = '1234 1234 1234 1235’
• the third script in the session, R = '1234 1234 1234 1236’
• Plaintext data in the APDU data field if data is present.
2. Pad the data block D by adding a '80' byte to the right of D, and then adding the least
number of '00' bytes to the right such that the length of resulting data block is a multiple
of 8 bytes.
3. Divide the result of padding D, into 8-byte blocks D1, D2, . . . , D4.
4. Generate the 8-byte MAC using D1, D2, . . . , DN, session key K = SKSMI and the algorithm
as described in Figure 34. Note: Depending on the length of data block D, there may be
less than or greater than four 8-byte data blocks to input to the algorithm.
5. The resultant value is the eight-byte MAC.
Figure 34 - MAC Generation
7.4 SECURE MESSAGING FOR CONFIDENTIALITY

Secure messaging for confidentiality is used when the command data sent to the card must
be encrypted to protect sensitive data.
Encryption of an APDU is carried out according to the following steps,
1. If the number of data bytes is not divisible by 8, pad the plaintext data (D) in the APDU
data field by adding a '80' byte to the right of D, and then adding the least number of '00'
bytes to the right such that the length of resulting data block is a multiple of 8 bytes.
2. Divide the result of padding D, into 8-byte blocks D1, D2, . . . , DN.
3. Compute for i = 1, 2, . . . , k:
Yi := DES3 (SKSMC)[Di EOR Yi-1],
where Y0 := '00' || '00' || '00' || '00' || '00' || '00' || '00' || '00'.
Decryption of Y with a session key SKSMC = (SKL || SKR) takes place in the following steps:
4. Compute for i = 1, 2, . . . , k:
Xi := DES3-1 (SKSMC)[Yi] EOR Yi-1,
where Y0 := '00' || '00' || '00' || '00' || '00' || '00' || '00' || '00'..
To obtain the original message D, concatenate the blocks D1, D2, . . . , Dk and remove the
trailing (‘80’ || ‘00’ || ‘00’ || . . . || ‘00’) byte-string from the last block Xk.
7.5 SECURE MESSAGING FOR INTEGRITY AND CONFIDENTIALITY

Secure messaging for Integrity and Confidentiality is used when APDU data in command must
be both encrypted and signed. In D-PAS, the only command requiring secure messaging for
integrity and confidentiality is the ‘PIN Change/Unblock.
Encrypting and MAC'ing of an APDU is carried out according to the following steps,
1. The plaintext command data is enciphered as described in section 0 to obtain the

enciphered command data.
2. The MAC is computed as described in section 7.3, with the command data being the
enciphered command data.
3. The new APDU data field consists of the concatenation of enciphered command data,
followed by the MAC.
8 SECURITY, CRYPTOGRAPHIC ALGORITHMS AND KEYS
8.1 APPLICATION CRYPTOGRAM GENERATION
8.1.1 DATA SELECTION

Table 83 lists the data elements to be included in the TC, ARQC and AAC Cryptogram
generation.
Table 83 - Data to Be Included in Application Cryptogram Generation
Data Element Source
Amount, Authorized Terminal
Amount, Other Terminal
Terminal Country Code Terminal
Terminal Verification Result Terminal
Transaction Currency Code Terminal
Transaction Date Terminal
Transaction Type Terminal
Unpredictable Number Terminal
Application Interchange Profile ICC
Application Transaction Counter ICC
Issuer Application Data (if CVN 5 selected), ICC

or, only CVR (if CVN 6 selected in ACO)
8.1.2 CRYPTOGRAM VERSION NUMBER (CVN)

The cryptogram version number (CVN) informs the issuer of the data used in the application
cryptogram generation process.
The following two CVN values are supported by D-PAS:
• CVN 5. This is the default CVN and indicates that Issuer Application Data is
included in the cryptogram generation (see Table 83). Note any data elements
requested in the IADOL will be included,
• CVN 6. This CVN is available as an option in the ACO. It indicates that only the
CVR is included in the cryptogram generation (see Table 83) instead of the
entire contents of Issuer Application Data.
8.1.3 TC, ARQC AND AAC CALCULATION

The D-PAS application computes the 8 byte TC, ARQC or AAC cryptogram generation
according to the following steps:
1. Derive a 16-byte Application Cryptogram Session Key SKAC from the ICC Application
Cryptogram Master Key MKAC and the 2-byte Application Transaction Counter (ATC) of the
ICC. Use the session key derivation function in section 8.2 to derive SKAC.
2. Concatenate the data in Table 83 in the order listed in the table, to give a data block D.
3. Pad the data block D by adding a '80' byte to the right of D, and then adding the least
number of '00' bytes to the right such that the length of resulting data block is a multiple
of 8 bytes.
4. Divide the result of padding D, into 8-byte blocks D1, D2, . . . , D5.
5. Generate the 8-byte TC, ARQC or AAC cryptogram using D1, D2, . . . , D5, session key K =
SKAC and the algorithm in Figure 35. Note: Depending on the length of data block D, there
may be less than or greater than five 8-byte data blocks to input to the algorithm.
Figure 35 - TC, ARQC and AAC Cryptogram Generation
D1
KL KL KL KL KL KR
DEA(e) DEA(e) DEA(e) DEA(e) DEA(e) DEA(d)
O1 O2 O3 O4 O5 O6
KL
DEA(e)
D2 D3 D4 D5 O7
D = Data block = Exclusive OR

O = Output operation
DEA(d) = Data Encryption Algorithm

(decipher mode)
DEA(e) = Data Encryption Algorithm
(encipher mode)
Key K consists of the concatenation

of a leftmost and a rightmost key block
K = (KL || KR).
8.1.4 ARPC GENERATION

The D-PAS mechanism for generating the 8-byte ARPC (Application Response Cryptogram)
used for Issuer Authentication is the EMV ARPC Method 1.
The D-PAS application computes the 8 byte ARPC cryptogram according to the following
steps,
1. Pad the 2 byte CSU by adding six '00' bytes to the right of the CSU, to obtain,
X := (CSU || '00'|| '00' || '00' || '00' || '00' || '00')
2. Compute
Y: = ARQC EOR X.
3. Compute the ARPC as follows,
ARPC := DES3 (SKAC) [Y]
8.2 SESSION KEY DERIVATION

D-PAS supports the common session key derivation option as per EMV 4.2 book 2 annex A1.3
to generate a unique session key.
The D-PAS computes session key according to the following steps,
In D-PAS, this is done by enciphering an 8-byte diversification value R, with the 16-byte ICC
Master Key (MK) to produce a 16-byte ICC Session Key (SK).
The diversification value R is represented as
R = R0 || R1 || R2 || R3 || R4 || R5 || R6 || R7
The D-PAS application computes SK according to the following steps,
4. Compute SKL, the left hand 8 bytes of SK,
SKL := DES3 (MK) [R0 || R1 || 'F0' || R3 || R4 || R5 || R6 || R7]
5. Compute SKR, the right hand 8 bytes of SK,
SKR := DES3 (MK) [R0 || R1 || '0F' || R3 || R4 || R5 || R6 || R7]
6. SK is the concatenation of SKL and SKR Compute SKL, the left hand 8 bytes of SK,
SK := SKL || SKR
For the session key used to generate and verify the cryptograms, TC, ARQC, AAC and ARPC,
the diversification value is the ATC followed by 6 bytes of '00':
R := ATC || '00' || '00' || '00' || '00' || '00' || '00'
For the session keys used for secure messaging, the diversification value R is the Application
Cryptogram returned in the response example to the 1st GENERATE AC command.
The same session key is used for all commands in a single transaction.
8.3 ICC DYNAMIC NUMBER GENERATION

The ICC Dynamic Number (IDN) is an unpredictable number generated by the ICC and
retrieved by the terminal during dynamic data authentication.
The ICC Unpredictable Number (the challenge) and the ICC Dynamic Number (as included in
DDA/CDA) shall both be 8-byte unpredictable numbers and so shall appear to be randomly
generated. This may be achieved using a Random Number Generator (RNG) provided by the
IC manufacturer.
8.4 SYMMETRIC KEYS

The D-PAS application uses symmetric DEA keys for application cryptogram generation and
verification and when processing issuer script commands. Table 84 lists the symmetric keys
and their lengths.
Table 84 - Symmetric keys used in the D-PAS application
Length
Key Description (bytes)
MKAC ICC Master Key used for Application Cryptogram Generation. 16

Generated by issuer and personalized into the application.
MKSMC ICC Master Key used for Secure Messaging for Confidentiality. 16
Generated by issuer and personalized into the application.
MKSMI ICC Master Key used for Secure Messaging for Integrity. Generated by 16
issuer and personalized into the application.
SKAC ICC Session Key used for Application Cryptogram Generation. Derived 16
from MKAC
SKSMC ICC Session Key used for Secure Messaging for Confidentiality. Derived 16
from MKSMC
SKSMI ICC Session Key used for Secure Messaging for Integrity. Derived from 16
MKSMI
APPENDIX A. ACRONYMS & GLOSSARY

TERM ACRONYM DEFINITION
Advanced Encryption AES A symmetric block cryptographic algorithm that

Standard can be used for the encryption, decryption, and
thereby the protection of electronic data.
Alternate AID (Alias) AltAID An alias AID by which the main D-PAS application
can be accessed.
American Standard Code ASCII A code based on a standard English character set
for Information of 128 7-bit characters.
Interchange
Amount Authorized Transaction amount authorized (excluding
adjustments).
Amount Other A secondary, cashback amount selected as part of
a chip card transaction.
Answer To Reset ATR The initial communication between a chip card
and terminal that verifies the ability of the chip
card to communicate with the terminal.
Application AAC The cryptogram generated by a D-PAS chip card
Authentication when a transaction is declined.
Cryptogram
Application Authorization AAR An Application Cryptogram generated by a card
Referral when requesting a referral for a transaction.
Application ACO An internal D-PAS global table listing the card
Configuration Options supported functions in addition to those defined
within the Application Interchange Profile.
Application Cryptogram AC The cryptogram computed by the D-PAS card
application and used by the issuer to verify that
(ARQC, TC, AAC)
the request came from the card.
Application File Locator AFL A list of files and records to be used in the
processing of a transaction.
Application Identifier AID Identifies the application saved in a chip card as
described in ISO/IEC 7816-5. The AID is made
up of the Registered Application Provider Identifier
(RID) and the Proprietary Identifier Extension
(PIX).
The terminal holds a list of all of the AIDs that it
supports.
Application Interchange AIP A card-generated list of functions required to
Profile process the transaction in progress.
Application Protocol APDU The command message sent from the application
Data Unit layer to the card, and the response message
returned by the card to the application layer.
Application Transaction ATC Global counter maintained by the card application
Counter in the chip card. (Incrementing the ATC is
managed by the chip.)
Application Usage AUC Indicates the issuer‘s specified restrictions on the

Control geographic usage and services allowed for the
application.
Application Version AVN Version number assigned by the D-PAS card
Number scheme to the application.
Authorization Request ARQC A cryptogram generated as a result of the ARQC
Cryptogram and the issuer’s authorization and used for Online
Issuer Authentication.
Authorization Response ARC Code that defines the disposition of a message.
Code
Basic Encoding Rules- BER-TLV A set of encoding rules for a data object. As
Tag Length Value defined in ISO/IEC 8825, a BER-TLV data object
consists of 3 consecutive fields:
The tag field (T) indicates a class, a type, and a
number.
The length field (L) indicates the length of the
following field.
The value field (V) indicates the value of the data
object
Binary Coded Decimal BCD A data format for numeric data elements which
consist of two numeric digits (having values in the
range Hex '0' – '9') per byte.
Card Action Codes CACs D-PAS application proprietary data element
indicating issuer-specified action for the card to
take for certain exception conditions.
Card Authentication CAM A method of validating whether a card used in a
Method transaction is a genuine card.
Card Risk Management CRM Risk management checks performed by the chip
application to protect the issuer from fraud or
excessive credit risk.
As a result of the risk management process, a
chip application may decide to complete a
transaction online or offline or reject the
transaction.
Card Risk Management CDOL1 A list of the tags and lengths of data elements
DOL for the First that must be passed to the ICC in the first
GENERATE AC command GENERATE AC command.
Card Risk Management CDOL2 A list of the tags and lengths of data elements
DOL for the Second that must be passed to the ICC in the second
GENERATE AC command GENERATE AC command.
Card Status Update CSU Data sent to the chip application to indicate
whether the issuer approves or declines the
transaction, and to initiate actions specified by the
issuer.
Card Verification Results CVR D-PAS card application proprietary data element
used to inform the issuer about exception
conditions that occurred during the current and
previous transactions. It is transmitted to the
terminal in Issuer Application Data.
Cardholder Activated CAT A Merchant’s unattended POS Device at which the
Terminal Cardholder’s signature is not required on the
Transaction Receipt in order to conduct a Card
Sale.
Cardholder Verification CVM Method used to ensure that the person presenting
Method the chip card is the person to whom the
application in the card was issued.
Certification Authority CA A trusted central party that issues and distributes
electronic certificates.
Chinese Remainder CRT
Theorem
Combined Dynamic Data CDA An authentication method that uses a dynamic
Authentication / signature and online application cryptogram
Application Cryptogram generated by the card
Generation
Common Core CCD A minimum common set of card application
Definitions implementation options, card application
behaviors, and data element definitions sufficient
to accomplish an EMV transaction.
Common Personalization CPS An EMVCo defined specification that standardizes
Specification EMV card personalization leading to faster, more
efficient and more economical solutions.
Common Session Key CSK A session key derivation method used to generate
a unique session key for each transaction
performed by the chip application.
Number of Consecutive NCOT D-PAS proprietary data element representing a
Offline Transactions profile-specific counter of consecutive offline
transactions that have occurred for that card
application since the last time a transaction went
online.
Cryptogram Information CID Indicates the type of cryptogram (TC, ARQC, or
Data AAC) returned by the card and the actions to be
performed by the terminal.
Cryptogram Version CVN D-PAS proprietary data element indicating the
Number version of the algorithm used by the card to
generate an Application Cryptogram (TC, ARQC,
AAC).
Cumulative Offline COA D-PAS proprietary data element representing a
Amount global counter of cumulative total amount of
offline transactions in the primary and secondary
currencies for the card application since the last
time a transaction went online.
D-Payment Application D-PAS Defines the technical requirements for the

Specification behavior of, and interaction between, chip cards
and chip card terminals in support of DFS
transactions that are based on the EMV™
specifications.
Data Elements DE Equivalent to “field” or “fields.”
Data Encryption DES An approved symmetric key cryptographic
Standard algorithm used in the encipherment and MAC
mechanisms.
Data Object List DOL A flexible list of data elements to be passed to the
card under the card‘s direction.
Dedicated File DF Defined in ISO/IEC 7816-4 and containing a FCI
mapped on to an ADF or a DDF.
Derivation Key Index DKI Specifies the issuer’s master key set used to
derive the card’s ICC Master keys
Directory DIR Equivalent to a ‘folder’ in application file structure
Discover Financial DFS A limited liability company duly established in the
Services State of Delaware, with its principle business
office at 2500 Lake Cook Road, Riverwoods, IL,
60015, United States of America
Dynamic Data DDA An authentication method that enables the
Authentication terminal to verify a dynamic signature generated
by the card which is different for each transaction.
In this instance, the private key is used to ensure
that the card is not counterfeit and that the card
data has not been altered
Dynamic Data Object DDOL List of data objects (tag and length) to be passed
List to the chip card in the INTERNAL AUTHENTICATE
command to perform Standard Dynamic Data
Offline Authentication.
Electrically Erasable EEPROM A non-volatile type of memory that allows data to
Programmable Read- be written and read under program control.
Only Memory
EMVCo LLC EMVCo manages, maintains and enhances the
EMV™ Integrated Circuit Card Specifications for
chip-based payment cards and acceptance
devices, including point of sale (POS) terminals
and ATMs. EMVCo also establishes and
administers testing and approval processes to
evaluate compliance with the EMV Specifications.
Europay MasterCard EMV EMV™ is a global standard for credit and debit
Visa payment cards based on chip card technology.
EMV is a trademark owned by EMVCo LLC.
Exclusive OR operation EOR Binary addition with no carry, giving the following
values:
0 + 0 = 0; 0 + 1 = 1; 1 + 0 = 1; 1 + 1 = 0
File Control Information FCI The information that is returned to the terminal in
response to a SELECT command.
GET PROCESSING GPO A command which initiates the transaction within
OPTIONS the chip application.
Hardware Security HSM An ISO 9564-1 compliant secure computational
Module device that is used to perform various
cryptographic functions.
Identifier ID
Integrated Circuit Card ICC A card that has a chip embedded in it, also called
a chip card.
Interface Device IFD That part of a terminal into which the ICC is
inserted, including such mechanical and electrical
devices as may be considered part of it.
International ISO An organization of international member countries
Organization for that develop and manage a broad range of
Standardization industry business standards.
Issuer Action Codes IACs Issuer action codes set up on the D-PAS card
during the personalization process and used to
designate the issuer’s selections for approving and
declining transactions. IACs include the:
IAC Default
Specifies the issuer‘s conditions that cause a
transaction to be rejected if it might have been
approved online, but the terminal is unable to
process the transaction online.
IAC Denial
Specifies the issuer‘s conditions that cause the
decline of a transaction without attempt to go
online.
IAC Online
Specifies the issuer‘s conditions that cause a
transaction to be transmitted online.
Issuer Application Data IAD Contains proprietary application data that must be
transmitted to the Issuer in an online transaction
in the authorization request and in the clearing
message, including the:
Length of data contained
Derivation Key Index
Cryptogram Version
Card Verification Results (CVRs)
Issuer Application Data IADOL Data element which allows the issuer to request
Object List additional data elements in the Issuer Application
Data.
Issuer Authentication Used to verify that the authorization response

was, in fact, generated by the issuer host.
Issuer Authentication IAD Data that must be sent from the issuer or its
Data proxy to the chip for online issuer authentication,
including the:
Response Cryptogram (ARPC)
Response Code
Issuer Defined Data Tag IDDT D-PAS proprietary data tags in the range DF01 to
DF0A which are available to the issuer for non
EMV use.
Issuer Discretionary IDD Issuer specified data relating to the application
Data which is part of the Issuer Application Data.
Issuer Identification IIN Number which identifies the Issuer of the Card.
Number
Issuer Life Cycle Data ILCD D-PAS application proprietary data element that
provides traceability of the chip card and its
personalization.
Kilo bytes (1024 bytes) KB 1024 bytes.
Length of the ICC PIN NPE Length of the ICC PIN encipherment public key
encipherment public key modulus
modulus
Length of the ICC public NICC Length of the ICC public key modulus
key modulus
Lower Consecutive LCOL D-PAS card application proprietary data element
Offline Transaction Limit specifying the maximum number of offline
transactions allowed for the transaction profile
before a transaction is forced to go online.
Lower Cumulative LCOA D-PAS application proprietary data element
Offline Transaction specifying the maximum total amount of offline
Amount Limit transactions in the primary and secondary
currencies allowed for the transaction profile
before a transaction is forced to go online.
Merchant Category Code MCC A code identifying the business type for a
particular Merchant.
Not Applicable N/A
One-Time-Password OTP A password that can be used for only one
authentication process.
Operating System OS
PAN Sequence Number PSN Identifies and differentiates cards with the same
PAN
Payment System PSE The set of logical conditions established within the
Environment ICC when a payment system application has been
selected, or when a DDF used for payment system
application purposes has been selected.
Personal Identification PIN A secret number is used to validate a

Number cardmember’s identity that is known only to the
cardmember.
PIN Try Counter PTC Number of PIN tries remaining
Previous Transaction PTH D-PAS application proprietary data element used
History to store in non-volatile memory information about
the previous transactions
Primary Account Number PAN The unique identifying number that is assigned by
the Issuer to the Card at the time of Card
issuance.
Personal Identification PIN A secret number used to validate a cardmember’s
Number identity that is known only to the cardmember.
Plaintext Unencrypted text used as input for cryptograms.
Processing Data Objects PDOL A list of terminal resident data elements (tags and
List lengths) provided by the terminal in response to a
GET PROCESSING OPTIONS command requested
by the chip card.
Profile Resource Usage PRU The Profile Resource Usage Bitmap that specifies
bitmap which profile-specific resources are defined in a
given transaction profile.
Proprietary Identifier PIX An optional field assigned by the application
Extension provider of up to 11 bytes which is part of the
structure of the AID.
Public Key PK
Public Key Infrastructure PKI
Read-Only Memory ROM
Registered Application RID Part of AID that is unique to an application
Provider ID provider and assigned according to ISO/IEC 7816-
5.
Reserved for Future Use RFU
Rivest, Shamir & RSA A reversible algorithm for encipherment and
Adleman digital signature generation.
RSA private Key SK
RSA Public Key PK
Secure Hash Algorithm SHA A hash algorithm as defined in ISO/IEC 10118-3.
Short File Identifier SFI Identifies the AEF referenced in commands related
to a given ADF or DDF. The SFI is a binary value
in the range 1 to 30, coded on the first 5 bits
[MSB] of a byte. Actual value is thus ‘left-shifted’
by 3 bits.
Signed Dynamic SDAD Dynamic digital signature generated by the card
Application Data on critical application parameters for DDA or CDA
and validated by the terminal
Signed Static Application SSAD Static digital signature generated by the issuer on
Data critical application parameters for SDA,
personalized in the card application and validated
by the terminal
Single Transaction STA D-PAS application proprietary data element
Amount Limit specifying the largest amount of a single
transaction, in the reference currency, allowed for
the card application/transaction profile before a
transaction is forced to go online
Static Data SDA An authentication method that uses the static
Authentication signature of the card data, which is the same for
every transaction, to ensure that this data has not
been altered.
Tag Length Value TLV See BER-TLV
Terminal Risk TRM Risk management performed by the terminal to
Management protect the acquirer, issuer, and system from
fraud
Transmission Protocol TPDU
Data Unit
Transaction Certificate TC The Cryptogram generated by the D-PAS chip card
when the transaction decision is to approve the
transaction offline
Triple DES 3DES A form of DES Encipherment/Decipherment.
Triple DES encipherment involves enciphering an
8-byte plaintext block in an 8-byte ciphertext
block with a double-length (16-byte) secret key.
Upper Consecutive UCOL D-PAS card application proprietary data element
Offline Transaction Limit specifying the maximum number of offline
transactions allowed for the transaction profile
before a transaction is declined after an online
transaction is unable to be performed.
Upper Cumulative UCOA D-PAS card application proprietary data element
Offline Amount Limit specifying the maximum cumulative amount of
offline transactions allowed for the transaction
profile, before a transaction is declined after an
online transaction is unable to be performed.
Variable Var.
Year-Day-Day-Day YDDD A date format.
APPENDIX B. DATA DICTIONARY

This section contains the definitions of the data elements in the application, including:
• An initial section containing a Data Elements summary table with their tags and usage
specified.
• Subsequent sections that provide more detailed descriptions of the data elements
described in the summary table.
1 DATA ELEMENT SUMMARY TABLE

This section defines all the Data Elements, their tag identification and access methods
supported by the application. The ‘P’ column indicates if the Data Element may be
personalized. Where a Tag is defined, the Data Element may be accessed as a Data Object
across the card-edge.
Table 85 - Data Elements Table
Data Element Abbr. Tag Access Method P Comment
AC Master Key - - - Y Internal access

Alternate Application AltAID ‘84’ SELECT FILE Y Each ‘AltAID’ has its own FCI
Identifier and PDOL list, and this
functionality allows the
payment application to be
selected according to multiple
Application IDs (for Regional
specifics).
Application ACO ‘C1’ GET DATA, PUT Y
Configuration Options DATA
Application AC '9F26' GEN AC N Internally generated
Cryptogram
Application Currency - ‘9F42’ READ RECORD, Y SFI
Code UPDATE RECORD
Application Currency - ‘9F44’ READ RECORD, Y SFI
Exponent UPDATE RECORD
Application - ‘9F05’ READ RECORD, Y SFI
Discretionary data UPDATE RECORD
Application Effective - ‘5F25’ READ RECORD, Y SFI
Date UPDATE RECORD
Application Expiration - ‘5F24’ READ RECORD, Y SFI
Date UPDATE RECORD
Application File AFL ‘94’ GPO Y
Locator
- GET DATA, PUT As part of a Transaction
DATA Profile Object for a specific
Profile
Application Identifier AID ‘4F’ SELECT FILE Y Embedded in ISO 7816

Template ‘61’ in FCI
Application AIP ‘82’ GPO Y
Interchange Profile
DATA Profile Object
Application Label - ‘50’ SELECT FILE Y Embedded in ISO 7816
Template ‘61’ in FCI
Application Preferred - ‘9F12’ READ RECORD, Y SFI
Name UPDATE RECORD
Application Primary PAN ‘5A’ READ RECORD, Y SFI
Account Number UPDATE RECORD
Application PAN PSN ‘5F34’ READ RECORD, Y SFI
Sequence Number UPDATE RECORD
Application Priority API ‘87’ SELECT FILE Y Embedded in ISO 7816
Indicator Template ‘61’ in FCI
Application ATC ‘9F36’ GEN AC, GET DATA N Internally generated
Transaction Counter
Application Usage AUC ‘9F07’ READ RECORD, Y SFI
Control UPDATE RECORD
Application Version AVN ‘9F08’ READ RECORD, N SFI
Number UPDATE RECORD
Authorization Code - ‘89’ GEN AC N D-PAS specific
Authorization ARC ‘8A’ GEN AC N
Response Code
Card Action Code - CAC- ‘C5’ GET DATA, PUT Y Update available only if this
Denial DN DATA resource is defined in the
current transaction profile.
Profile
Card Action Code – CAC-DF ‘C6’ GET DATA, PUT Y Update available only if this
Default DATA resource is defined in the
Profile
Card Action Code – CAC-OL ‘C7’ GET DATA, PUT Y Update available only if this
Online DATA resource is defined in the
Profile
Card Risk CDOL1 ‘8C’ READ RECORD, Y SFI
Management Data UPDATE RECORD

Object List 1
Card Risk CDOL2 ‘8D’ READ RECORD, Y SFI
Management Data UPDATE RECORD
Object List 2
Card Verification CVR ‘9F52’ GEN AC N Internally generated as part
Results of IAD ‘9F10’
Cardholder Name - ‘5F20’ READ RECORD, Y SFI
UPDATE RECORD
Cardholder Name - ‘9F0B’ READ RECORD, Y SFI
Extended UPDATE RECORD
Card Status Update CSU - GEN AC - CDOL2 N Returned to the card in online
Command data Authorization Response, in
Issuer Authentication Data
Cardholder CVM ‘8E’ READ RECORD, Y SFI
Verification Method UPDATE RECORD
List
Certification Authority - ‘8F’ READ RECORD, Y SFI
Public Key Index UPDATE RECORD
CRM Country Code - ‘D2’ PUT DATA, GET Y Internal access
DATA
CRM Currency Code - ‘D3’ PUT DATA, GET Y Internal access
DATA
Cryptogram CID ‘9F27’ GEN AC N
Information Data
Cryptogram Version CVN - GEN AC Y Part of IAD ‘9F10’. Specifies
Number session key derivation
mechanism used by the card.
Can be ‘05’ or ‘06’, depending
on Issuer configuration choice
Cumulative Offline COA ‘CE’ GEN AC, GET DATA N Global CRM resource, used in
Amount all profiles
Currency Conversion CCC1 ‘C3’ GET DATA, PUT Y
Code 1 DATA
Currency Conversion CCC2 ‘C4’ GET DATA, PUT Y
Code 2 DATA
Derivation Key Index DKI - GEN AC Y Part of IAD ‘9F10’
Dynamic Data DDOL ‘9F49’ READ RECORD, Y SFI
Authentication Data UPDATE RECORD
Object List
File Control FCI ‘A5’ SELECT N
Information
ICC Dynamic Number IDN ‘9F4C’ GEN AC N
ICC PIN - - - Y Internal access

Encipherment Private
Key
ICC PIN - ‘9F2D’ READ RECORD, Y SFI
Encipherment Public UPDATE RECORD
Key Certificate
ICC PIN - ‘9F2E’ READ RECORD, Y SFI
Key Exponent
ICC PIN - ‘9F2F’ READ RECORD, Y SFI
Key Remainder
ICC Private Key - - - Y Internal access
ICC Public Key - ‘9F46’ READ RECORD, Y SFI
Certificate UPDATE RECORD
Remainder UPDATE RECORD
ICC Unpredictable - - GET CHALLENGE N Internally generated
Number
Issuer Action Code – IAC-DF ‘9F0D’ READ RECORD, Y SFI
Default UPDATE RECORD
Issuer Action Code – IAC-DC ‘9F0E’ READ RECORD, Y SFI
Denial UPDATE RECORD
Issuer Action Code – IAC-OL ‘9F0F’ READ RECORD, Y SFI
Online UPDATE RECORD
Issuer Application IAD ‘9F10’ GEN AC N
Data
Issuer Application IADOL ‘D0’ GET DATA, PUT Y
Data Object List DATA
Issuer Authentication - '91' GEN AC N Returned to the card in online
Data Authorization Response
Issuer Code Table - ‘9F11’ SELECT, READ Y As part of FCI, optionally in
Index RECORD, UPDATE SFI
RECORD
Issuer Country Code - ‘5F28’ READ RECORD, Y SFI
UPDATE RECORD
Issuer Defined Data IDDT0- ‘DF01’ – GET DATA, PUT Y 10 predefined Tags
Tags ‘DF0A’ DATA
IDDT9
Issuer Discretionary IDD - GEN AC N Discretionary part of IAD
Data ‘9F10’
Issuer Life Cycle Data ILCD ‘C2’ GET DATA Y
Issuer Public Key - ‘90’ READ RECORD, Y SFI

Certificate UPDATE RECORD
Issuer Public Key - ‘9F32’ READ RECORD, Y SFI
Issuer Public Key - ‘92’ READ RECORD, Y SFI
Remainder UPDATE RECORD
Issuer Script Counter - - CVR – GEN AC N Stored in Byte 2 of PTH.
Lower nibble copied into CVR.
Reset on successful online
transaction unless issuer
authentication data received,
issuer authentication
succeeds, and Byte 2, bit 6 of
CSU is set.
Language Preference - ‘5F2D’ READ RECORD, Y Also as part of FCI
SELECT
Lower Consecutive LCOL ’CB’ GET DATA Y Accessed by D-PAS defined
Offline Limit tag. (Note: This is not the
EMV element used in terminal
velocity checking)
‘CB’ PUT DATA Update available only if this
resource is defined in the
Profile.
Lower Cumulative LCOA ‘C8’ GET DATA, PUT Y Update available only if this
Offline Amount Limit DATA resource is defined in the
Profile.
Number of NCOT ‘CD’ GET DATA N
Consecutive Offline
Transactions
Profile.
Offline Balance - ‘D1’ GET DATA N Computed value = UCOA-COA
Processing Options PDOL ‘9F38’ SELECT FILE Y FCI – BF0C template
Data Objects List
PDOL Check Table – PDOLD ‘DF10’ GET DATA, PUT Y
Denial DATA
PDOL Check Table – PDOLP ‘DF11’ GET DATA, PUT Y
Profile DATA
PDOL Check Table – PDOLO ‘DF12’ GET DATA, PUT Y

Online DATA
PIN Try Counter PTC ‘9F17’ GET DATA N Internally generated
nd
- GEN AC (2 ) Update via CSU
- PIN
CHANGE/UNBLOCK
PIN Try Limit - - - Y Internal access
Previous Transaction PTH ‘CF’ - N Internal access
History
Reference PIN - - - Y Internal access
Service Code - ‘5F30’ READ RECORD, Y SFI
UPDATE RECORD
Transaction Profile TPO0 – ‘DF20’ – GET DATA, PUT Y Encapsulates a number of
Objects ( min 3, max TPO15 ‘DF2F’ DATA Profile specific Data Elements
15)
Profile Resource - - GET DATA, PUT Y As part of a Transaction
Usage Bitmap DATA Profile Object for a specific
Profile
SDA Tag List - ‘9F4A’ READ RECORD, Y SFI
UPDATE RECORD
Signed Dynamic SDDA ‘9F4B’ INTERNAL N Internally generated
Application Data AUTHENTICATE
Signed Static SSAD ‘93’ READ RECORD, Y Encrypted Hash of contents of
Application Data UPDATE RECORD all signed records + AIP
Security Limit - - - N Internal access
Single Transaction STA ‘CA’ GET DATA, PUT Y Update available only if this
Amount Limit DATA resource is defined in the
Profile
SMC Master Key - - - Y Internal access
SMI Master Key - - - Y Internal access
Track 2 equivalent - ‘57’ READ RECORD, Y SFI
data UPDATE RECORD
Track 1 Discretionary - ‘9F1F’ READ RECORD, Y SFI
data UPDATE RECORD
Transaction Log - ‘9F4D’ SELECT FILE Y FCI – BF0C template
Entry
Transaction Log - ‘9F4F’ GET DATA Y
Format
Upper Consecutive UCOL ‘CC’ GET DATA Y Accessed by D-PAS defined

Offline Limit tag. (Note: This is not the
EMV element used in terminal
velocity checking)
‘CC’ PUT DATA Update available only if this
resource is defined in the
Profile
Upper Cumulative UCOA ‘C9’ GET DATA, PUT Y Update available only if this
Offline Amount Limit DATA resource is defined in the
Profile
2 DATA ELEMENTS
The Data Element Format definition follows those in EMV.
3 ICC MASTER KEY APPLICATION CRYPTOGRAM (ICC MKAC)

ICC Master Key for the Application Cryptogram Generation.
Format: Binary, 16 bytes.
4 ALTAIDS (ALIASES)
Alternate AIDs (AltAIDs) are alternative application identifiers that point to an existing
application in addition to the AID of the application.
Each ‘AltAID’ has its own FCI and PDOL list, and this functionality allows the payment
application to be selected according to multiple Application IDs (for Regional specifics).
5 APPLICATION CRYPTOGRAM (AC)

Cryptogram computed by the D-PAS application and returned to the terminal in the response
of the GENERATE AC command (i.e., TC, ARQC, AAC).
The D-PAS application does not support AAR generation (Application Advice Request).
The type of cryptogram contained in the Application Cryptogram is identified by the contents
of the Cryptogram Information Data (CID).
Application Cryptogram is a transient data element. The ICC returns an ARQC, a TC, or AAC in
response to the 1st GENERATE AC command; it may only return a TC or an AAC in response
to the 2nd GENERATE AC command.
Format: Binary, 8-bytes.
6 APPLICATION CONFIGURATION OPTIONS (ACO)

The Application Configuration Options is an internal global table listing the card supported
functions in addition with Application Interchange Profile.
This data allow the issuer to:
• Select cryptographic options
• Configure access rights
• Activate or de-activate functions in the application
Application Configuration Options is used for Card Action Analysis.
Note: If Issuer Authentication is supported in the D-PAS application, the ACO B1b5 bit should
be set. The AIP B1b3 bit refers to Issuer authentication performed in a separate ‘External
authenticate’ command. This command is not implemented in the D-PAS application, (Issuer
authentication is performed during 2nd GENERATE AC) and therefore this bit should never be
set.
Table 86 - Application Configuration Options (ACO) Encoding
BYTE 1:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 - - - - - - - Off-line enciphered PIN verification supported

(RFU for SDA-only application)
- 1 - - - - - - Separate Key pair used for Off-line enciphered
PIN verification (RFU for SDA-only application)
- - 1 - - - - - Skip CAC Default check on CAT3 Terminals
- - - 1 - - - - Partial Chip Implementation authorization
response accepted
- - - - 1 - - - Reset Offline counters during Partial Chip
Implementation transaction.
- - - - - 1 - - Transaction Logging is supported: Log Approved
transactions
- - - - - - 1 - Transaction Logging is supported: Log Online
Requested transactions
- - - - - - - 1 Transaction Logging is supported: Log Declined
off-line and on-line transactions
BYTE 2:
1 - - - - - - - Off-line plaintext PIN verification supported

- 1 - - - - - - Include only CVR in input data for Application
Cryptogram*
- - 1 - - - - - Use of Issuer Discretionary Data (IDD)/IADOL in

Issuer Application Data
- - - 1 - - - - Enable Issuer Defined Data Tags (IDDT)
- - - - 1 - - - Activate / Enable all predefined PDOL Checks
- - - - - 0 - - RFU
- - - - - - 1 - READ RECORD, and GET DATA only after GPO
- - - - - - - 1 Allow retrieval of values and limits of counters, as
well as ‘Offline balance’.
* Note: If this bit is not set, all of the IAD elements [including CVR and IADOL elements] will
be used.
7 APPLICATION CURRENCY CODE (9F42)

Indicates the currency in which the account is managed according to ISO4217.
This data object must be present if the CVM List contains a condition code value of ‘06’, ‘07’,
‘08’, or ‘09’.
8 APPLICATION CURRENCY EXPONENT (9F44)

Indicates the implied position of the decimal point from the right of the amount represented
according to ISO 4217.
The decimal point location of amounts expressed in the currency code specified in the
Application Currency Code.
This Data Object must be present if the CVM List contains a condition code value of:
‘06’, ‘07’, ‘08’, or ‘09’.
Format: Binary, 1 byte.
9 APPLICATION DISCRETIONARY DATA

Issuer Discretionary data [Optional]. Contained in Terminal file records.
Tag: 9F05
Format: Binary, 1 - 32 bytes.
10 APPLICATION EFFECTIVE DATE

Date from which the application may be used. Contained in Terminal File records.
Tag: 5F25
11 APPLICATION EXPIRATION DATE

Date after which the application is no longer valid. Contained in Terminal File records.
Tag: 5F24
12 APPLICATION FILE LOCATOR (AFL)

Indicates the location (SFI, range of records) of the Application Elementary Files (AEFs)
associated with a particular profile, and read by the terminal during a transaction. For details,
see EMV Book 3, section 10.2.
The AFL is a list identifying the files and records to be used in the processing of a transaction.
The terminal must only read the records named in the AFL.
With a maximum size of 32 bytes, a limit of 8 SFIs can be referenced in the AFL of the D-PAS
application.
Format: Binary, 32 bytes with each SFI listed in the AFL requiring 4 bytes.
Figure 36 - Structure of an Application File Locator (AFL) entry
Table 87 - AFL Description
Byte Acceptable Range Description
B1 NA The first five MSB contain the SFI number.

The three LSB bits shall always be 0.
B2 Never 0 The first/only record number read from the file.
B3 >=B2 The last record number to be read from the file.
If (B3 > B2) read records B2 to B3 from the file.
If (B3 == B2) read record B2 from the file.
B4 0 to (B3-B2)+1 Number of records involved in Offline Data Authentication.
Starting from B2
13 APPLICATION IDENTIFIER (AID)

The AID identifies the application as described in ISO/IEC 7816-5. The AID is made up of the
Registered Application Provider Identifier (RID) and the Proprietary Identifier Extension (PIX).
For details, see EMV Book 1, section 12.2.1.
The AID is used by the Terminal for application selection. For D-PAS applications:
• The RID is A000000152.
• The PIX value for D-PAS Credit application is 3010.
Note: Additional PIX values may be defined by Discover Financial Services, in order to meet
specific market / franchisee requirements
14 APPLICATION INTERCHANGE PROFILE (AIP)

The AIP indicates the capabilities of the card to support specific functions in the application.
Table 88 - Application Interchange Profile (AIP) Encoding
BYTE 1 (Leftmost)
0 - - - - - - - RFU
- 1 - - - - - - SDA supported
- - 1 - - - - - DDA supported
- - - 1 - - - - Cardholder verification is supported
- - - - 1 - - - Terminal risk management is to be

performed
- - - - - 1 - - Issuer authentication is supported
- - - - - - 0 - RFU
- - - - - - - 1 CDA supported
BYTE 2 (Rightmost)
0 - - - - - - - RFU
- 0 - - - - - - RFU
- - 0 - - - - - RFU
- - - 0 - - - - RFU
- - - - 0 - - - RFU
- - - - - 0 - - RFU
- - - - - - 0 - RFU
- - - - - - - 0 RFU
Note: If Issuer Authentication is supported in D-PAS, the ACO B1b5 bit should be set. AIP
B1b3 bit refers to Issuer authentication performed during a separate ‘External authenticate’
command, is not used in D-PAS and should not be set.
15 APPLICATION LABEL
Mnemonic associated with AID according to ISO/IEC 7816-5. Used in application selection.
Application Label is mandatory in the File Control Information (FCI) of an Application

Definition File (ADF) and mandatory in an ADF directory entry.
Format: Alphanumeric with special character limited to space, 1-16 bytes.
16 APPLICATION PREFERRED NAME

Preferred mnemonic associated with the AID.
Format: Alphanumeric with special character, 1-16 bytes.
17 APPLICATION PRIMARY ACCOUNT NUMBER (PAN)

Valid cardholder account number. Contained in Terminal File records.
Odd length PANs are padded with hex ‘F’ for storage in the ICC. Recommendation: pad with a
maximum of 1 ‘F’.
Tag: 5A
Format: Compressed numeric, 10 bytes.
18 APPLICATION PRIMARY ACCOUNT NUMBER SEQUENCE NUMBER (PSN)

Identifies and differentiates cards with the same PAN. Contained in Terminal File records.
Tag: 5F34
Format: Numeric, 1 byte.
19 APPLICATION PRIORITY INDICATOR (API)

Indicates the priority of a given application or group of applications in a directory.
Issuers must pay attention to the setting of bit 8 of the Application Priority Indicator. If the bit
is set, the associated application is not eligible at terminals that do not support a terminal
customer dialogue cardholder confirmation facility, such as vending machines and toll gates.
A priority indicator value of 1 indicates the highest priority.
Table 89 - Application Priority Indicator (API) Encoding
BYTE 1
1 - - - - - - - Application may not be selected without

confirmation of cardholder
- 0 0 0 - - - - RFU
- - - - X X X X No priority Assigned/Order in which
application is to be listed or selected
20 APPLICATION TRANSACTION COUNTER (ATC)

Global counter maintained by the card application in the ICC.
The value of the ATC may be obtained from the application using the GET DATA command.
The issuer may specify access right after a GET PROCESSING Command through ACO.
The right nibble is included in the Card Verification Results.
ATC is incremented by ICC when GET PROCESSING OPTIONS command is successfully

processed.
ATC is never reset.
As a part of security counters, the issuer may set ATC Limit. If ATC Limit is reached, the D-
PAS application is disabled.
21 APPLICATION USAGE CONTROL (AUC)

Indicates issuer’s specified restrictions on the geographic usage and services allowed for the
application.
Table 90 - Application Usage Control (AUC) Encoding
BYTE 1 (Leftmost)
1 - - - - - - - Valid for domestic cash transactions

- 1 - - - - - - Valid for international cash transactions
- - 1 - - - - - Valid for domestic goods
- - - 1 - - - - Valid for international goods
- - - - 1 - - - Valid for domestic services
- - - - - 1 - - Valid for international services
- - - - - - 1 - Valid at ATMs
- - - - - - - 1 Valid at terminals other than ATMs
BYTE 2 (Rightmost)
1 - - - - - - - Domestic cashback allowed

- 1 - - - - - - International cashback allowed
- - 0 - - - - - RFU
- - - 0 - - - - RFU
- - - - 0 - - - RFU
- - - - - 0 - - RFU
- - - - - - 0 - RFU
- - - - - - - 0 RFU
22 APPLICATION VERSION NUMBER (AVN)

Version number assigned by the D-PAS Scheme to the Application. The AVN identifies the
format of the Issuer Application Data and the CVR used. Contained in Terminal File Records.
The current D-PAS application version number is ‘0001’.
Tag: 9F08
23 AUTHORIZATION CODE
Value generated by the issuer for an approved transaction.
24 AUTHORIZATION RESPONSE CODE (ARC)

Code that defines the disposition of an online authorization request.
The ARC is an ISO 8583 response code received by the terminal from the issuer via the
network, or a response code generated by the terminal. The following values are allowed:
At fir1st GENERATE AC:
• Y1: offline approved
• Z1: offline declined
At 2nd GENERATE AC:
• Y3: Unable to go online - offline approved
• Z3: Unable to go online - offline declined
Format: Alphanumeric, 2 bytes.
For details, see EMV Book 4, Annex A, Table 34.
25 CARD ACTION CODES (CACS)

D-PAS application proprietary data elements indicating issuer-specified action for the card to
take for certain exception conditions.
Each profile contains Card Action Codes for Denial, Default, and Online. Each CAC is compared
to the Card Verification Results to take transaction decisions.
CAC bytes 1 and 2 match CVR bytes 4 and 5.
• CAC - Denial Used by the issuer to set the situations when a transaction is
always declined at the 1st GENERATE AC.
• CAC - Online Used by the issuer to set the situations when a transaction goes
online if the terminal is online-capable.
• CAC - Default Used by the issuer to set the situations when a transaction is
declined if the terminal is not online-capable or if connection to the issuer is not
possible.
Table 91 - Card Action Code (CAC) Encoding
BYTE 1
1 - - - - - - - Unable to go on-line during previous transaction

- 1 - - - - - - Issuer Authentication not performed during previous
online transaction.
- - 1 - - - - - Issuer Authentication failed during previous
transaction
- - - 1 - - - - Script received on previous transaction
- - - - 1 - - - Script failed on previous transaction
- - - - - 1 - - PTH forced on-line (‘Go online next transaction’)
- - - - - - 1 - PDOL forced on-line (during GPO)
- - - - - - - 1 PDOL forced decline (during GPO)
BYTE 2
1 - - - - - - - Invalid PDOL check

- 1 - - - - - - Off-line PIN verification failed
- - 1 - - - - - PIN Try Limit exceeded
- - - 1 - - - - Lower Consecutive Offline Transaction limit exceeded
(LCOL)
Note: May be profile-specific
- - - - 1 - - - Upper Consecutive Offline Transaction limit exceeded
(UCOL).
- - - - - 1 - - Lower Cumulative Offline Transaction Amount limit
exceeded (LCOA).
- - - - - - 1 - Upper Cumulative Offline Transaction Amount limit
exceeded (UCOA).
- - - - - - - 1 Single Transaction Amount limit exceeded (STA).
Note: Bits shaded in Blue are not significant in the CAC-denial array
26 CARD RISK MANAGEMENT DATA OBJECT LIST 1 (CDOL1)

CDOL1 is a list of the tags and lengths of data elements that must be passed to the ICC in the
1st GENERATE AC command.
Table 92 - Content of the CDOL1:
Tag Data Element Length
9F02 Amount, Authorized 6
9F03 Amount, Other 6
9F1A Terminal Country Code 2
95 Terminal Verification Results 5
5F2A Transaction Currency Code 2
9A Transaction Date 3
9C Transaction Type 1
9F37 Unpredictable Number 4
9F35 Terminal Type 1
9F34 CVM Results 3
Table 93 CDOL1 Content
27 CARD RISK MANAGEMENT DATA OBJECT LIST 2 (CDOL2)

CDOL2 is a list of the tags and lengths of data elements that must be passed to the ICC in the
2nd GENERATE AC command.
Content of the CDOL2:
Table 94 - CDOL2 Content
91 Issuer Authentication Data 10
8A Authorization Response Code 2
95 Terminal Verification Results 5
Note: If Issuer Authentication Data is not received, the application uses 10 bytes of '00' to
represent issuer authentication data in CDOL2.
28 CARD STATUS UPDATE (CSU)

Contains data sent to the ICC to indicate whether the issuer approves or declines the
transaction, and to initiate actions specified by the issuer.
Transmitted to the card in Issuer Authentication Data.
Table 95 - Card Status Update (CSU) Encoding
BYTE 1
0 0 0 0 - - - - RFU
- - - - X X X X PIN Try Counter
BYTE 2
0 0 - - - - - - RFU
- - 1 - - - - - DO NOT Reset Script Counter
- - - 1 - - - - Issuer Approves Online Transaction
- - - - 1 - - - Update PIN Try Counter. If the PTC value in
CSU B1b4-b1 > PTL then PTC is updated
with PTL value.
- - - - - 1 - - Set Go Online on next transaction
- - - - - - X X Update Counters
- - - - - - 0 0 Do Not Update Offline Counters
- - - - - - 0 1 Set Offline Counters to Upper Limits
- - - - - - 1 0 Reset Offline Counters to Zero
- - - - - - 1 1 Reset Offline Counters in all profiles to Zero
29 CARD VERIFICATION RESULTS (9F52)

The Card Verification results (CVR) is a D-PAS application proprietary data element used to
inform the issuer about exception conditions that occurred during the current and previous
transactions. It is transmitted to the terminal in Issuer Application Data.
The CVR is used with CACs and ACO during Card Action Analysis and allows the card
application to take a decision on acceptable offline risk.
The value of CVR is sent to the issuer as part of Issuer Application Data.
Table 96 - Card Verification Results (CVR) Encoding
BYTE 1
X X - - - - - - AC Type Returned in 2nd GENERATE AC

0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - 2nd GENERATE AC not requested
1 1 - - - - - - RFU
- - X X - - - - AC Type Returned in 1st GENERATE AC

- - 0 0 - - - - AAC
- - 0 1 - - - - TC
- - 1 0 - - - - ARQC
- - 1 1 - - - - RFU
- - - - 0 0 0 0 RFU
BYTE 2
1 - - - - - - - DDA Returned (if supported by card)

- 1 - - - - - - CDA returned in 1st GENERATE AC (if supported
by card)
- - 1 - - - - - CDA returned in 2nd GENERATE AC (if supported
by card)
- - - 1 - - - - Off-line PIN Verification performed
- - - - 1 - - - Off-line Enciphered PIN Verification performed (if
supported by card)
- - - - - 1 - - Off-line PIN Verification Successful
- - - - - - 1 - CAC-default ignored with CAT3 terminal
- - - - - - - 0 RFU
BYTE 3
X X X X - - - - Right nibble of Script Counter

- - - - X X X X Right nibble of PIN try Counter
BYTE 4
1 - - - - - - - Unable to go on-line during previous transaction
- 1 - - - - - - Issuer Authentication not performed during

previous online transaction.
- - 1 - - - - - Issuer Authentication failed during previous
transaction
- - - 1 - - - - Script received on previous transaction
- - - - 1 - - - Script failed on previous transaction
- - - - - 1 - - PTH forced on-line (‘Go online next transaction’)
- - - - - - 1 - PDOL forced on-line (during GPO)
- - - - - - - 1 PDOL forced decline (during GPO)
BYTE 5
1 - - - - - - - Invalid PDOL check

- 1 - - - - - - Off-line PIN verification failed
- - 1 - - - - - PIN Try Limit exceeded
- - - 1 - - - - Lower Consecutive Offline Transaction limit
exceeded (LCOL).
- - - - 1 - - - Upper Consecutive Offline Transaction limit
exceeded (UCOL).
- - - - - 1 - - Lower Cumulative Offline Transaction Amount limit
exceeded (LCOA).
- - - - - - 1 - Upper Cumulative Offline Transaction Amount limit
exceeded (UCOA).
- - - - - - - 1 Single Transaction Amount limit exceeded (STA).
BYTE 6
X X X X - - - - ID of PDOL-Decline or PDOL-Online check that

forced the transaction to be declined or to go
online (Only valid if byte 4, bit 2 or 1 of CVR is
set).
- - - - X X X X Transaction profile Identifier (0000 by default)
30 CARDHOLDER NAME
Indicates cardholder name according to ISO 7813.
Format: Alphanumeric, 2 to 26 bytes.
31 CARDHOLDER NAME EXTENDED

Extends Cardholder Name to 45 bytes if required.
Format: Alphanumeric, 1 to 18 bytes.
32 CARDHOLDER VERIFICATION METHOD (CVM) LIST

Identifies a prioritized list of methods of verification of the cardholder supported by the
application. Each entry in the list specifies a method, encoded in 2 bytes:
Table 97 - Cardholder Verification Method Rule Encoding

CVM Code (left most 2 bits)
Fail cardholder verification if this CVM is unsuccessful 00b
Apply succeeding CV Rule if this CVM is unsuccessful 01b
CVM Type (the next 6 bits)
Fail CVM processing 000000b
Plaintext PIN verification performed by ICC 000001b
Enciphered PIN verified online 000010b
Plaintext PIN verification performed by ICC and signature 000011b
Enciphered PIN verification performed by ICC 000100b
Enciphered PIN verification performed by ICC and signature 000101b
Signature (paper) 011110b
No CVM required 011111b
CVM condition (right byte)
Always ‘00’
If unattended cash ‘01’
If not unattended cash and not manual cash and not

‘02’
purchase with cashback
If terminal supports the CVM ‘03’
If manual cash ‘04’
If purchase with cashback ‘05’
If transaction is in the application currency and is under X

‘06’
value
If transaction is in the application currency and is over X

‘07’
value
If transaction is in the application currency and is under Y

‘08’
value
If transaction is in the application currency and is over Y

‘09’
value
33 CERTIFICATE AUTHORITY PUBLIC KEY INDEX (PKI)

Identifies the DFS Certificate Authority Public Key/Private Key pair used in offline static and
dynamic data Authentication (SDA, DDA, and CDA, Offline Enciphered PIN supported)
34 CRM COUNTRY CODE

Internal card data element, used in Card Risk Management to identify International /
Domestic transactions. Equivalent to EMV element ‘5F28’, which is located in Terminal file
records.
Tag: ‘D2’
35 CRM CURRENCY CODE

Internal card data element, used in Card Risk Management to identify transaction currency,
and apply currency conversion parameters. Equivalent to EMV element ‘9F42’, which is
located in Terminal file records.
Tag: ‘D3’
36 CRYPTOGRAM INFORMATION DATA (CID)

Indicates the type of cryptogram (TC, ARQC, or AAC) returned by the card and the actions to
be performed by the terminal.
The D-PAS application doesn’t support referral.
Table 98 - Cryptogram Information Data (CID) Encoding
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - ARQC
- - X X - - - - Payment System Specific
- - - - 1 - - - Advice required
- - - - - X X X Reason/advice/referral code
- - - - - 0 0 0 No information given
- - - - - 0 0 1 Service Not Allowed
- - - - - 0 1 0 PIN Try Limit exceeded
- - - - - 0 1 1 Issuer authentication failed
- - - - - X X X Other value RFU
37 CRYPTOGRAM VERSION NUMBER (CVN)

D-PAS proprietary data element indicating the version of the algorithm used by the card to
generate an Application Cryptogram (TC, ARQC, AAC).
The value of CVN is sent to the issuer as part of the Issuer Application Data.
In D-PAS the value may be either of:
• '05'. CVN 5 is the default CVN and indicates that Issuer Application Data is
included in the cryptogram generation (see Table 83),
• '06'. CVN 6 is available as an option in the ACO. It indicates that the CVR is
included in the cryptogram generation (see Table 83) instead of Issuer
Application Data.
Format: Numeric, 1 byte.
38 CUMULATIVE OFFLINE AMOUNT (COA)

D-PAS proprietary data element representing a global counter of cumulative total amount of
offline transactions in the in the primary and secondary currencies for the card application
since the last time a transaction went online.
COA is used to perform card velocity checking.
COA is initialized to zero and incremented by the amount authorized each time a transaction
in the reference currency is completed offline.
COA is reset to zero when a transaction is online approved by issuer, Issuer Authentication
succeeds, and appropriate CSU bit is set.
Option: Reset to zero when a transaction is online approved by issuer, regardless of whether
Issuer Authentication Data is received and/or is successfully verified.
The value of COA may be sent to the issuer as part of the Issuer Application Data (if COA tag
is included in IADOL). If COA is in issuer application data, and the appropriate configuration
item is set, it may also be included in Application Cryptogram.
Format: n12, 6 bytes.
39 CURRENCY CONVERSION CODE 1, 2

D-PAS application proprietary data element allowing accumulation of offline transaction
amounts in a secondary currency.
The Currency Conversion Code is used to convert transactions in a recognized currency code
into the primary currency code. The application increments COA with the converted amount.
An Issuer Script may be used to modify this data element.
Table 99 - Currency Conversion Code Content
Byte Data Length
1-2 Secondary Currency Code (according to ISO 4217.) 2

Conversion rate: Decimal BCD coding of the multiplication factor used to convert the
3-4 Secondary Application Currency Code to the card’s Primary Application Currency Code 2
5 Conversion exponent: A signed number used to indicate the power of 10 used to modify
the Conversion Rate with b1-b7 indicating the value of the exponent and b8 indicating
the sign.
If(b8 = 1b) sign is negative
Conversion exponent(b7 to b1)
Approximate Value = Transaction Amount * Conversion Rate)/10
If(b8 = 0b) sign is positive
Conversion exponent(b7 to b1)
Approximate Value = Transaction Amount * Conversion Rate *10
Note: Approximate Value must never be larger than 999999999999 1
Example:
To convert a transaction amount of 1 Canadian Dollar (CAD) to United States Dollar (USD).
Data
1 CAD = 000000000100
Primary Application Currency Code: 0840 (USD)
Secondary Application Currency Code: 0124 (CAD)
Conversion rate: 0923
Conversion exponent: 83
Currency Conversion Code = 0124 0923 83
Calculation
(000000000100 * 0923)/103 = 000000000092 (0.92 USD)
1 CAD = 0.92 USD
40 DERIVATION KEY INDEX (DKI)

Specifies the IMK set that is used as the seed to derive the following chip master keys, which are used in
the D-PAS application:
• IMK Application Cryptogram Generation (IMKAC) key,
• IMK Secure Messaging for Integrity IMKSMI) key, and
• IMK Secure Messaging for Confidentiality (IMKSMC) key
The value of DKI is sent to the issuer as part of the Issuer Application Data
41 DYNAMIC DATA AUTHENTICATION DATA OBJECT LIST (DDOL)

List of data objects (tag and length) to be passed to the ICC in the INTERNAL AUTHENTICATE
command to perform Standard Dynamic Data Offline Authentication.
Content of the DDOL:
Table 100 - DDOL Content
42 FILE CONTROL INFORMATION (FCI)

Contains application information and is returned as response data in a SELECT command. This
is a constructed data object. Refer to Table 69 for its definition.
43 ICC DYNAMIC DATA

Dynamic application data included in the generation of the dynamic signature for the card for
DDA or CDA.
Format: Binary, 9 or 38 bytes.
44 ICC DYNAMIC DATA FOR DDA
Table 101 - ICC Dynamic Data for DDA
Data Element Length
ICC Dynamic Number Length 1
ICC Dynamic Number 8
ICC Dynamic Data for CDA:
Table 102 - ICC Dynamic Data for CDA
Data Element Length
ICC Dynamic Number Length 1
ICC Dynamic Number 8
CID 1
Application Cryptogram 8
Transaction Data Hash Code 20
45 ICC DYNAMIC NUMBER

Time-variant number generated by the ICC, to be extracted from a DDA / CDA certificate by
the terminal. If dynamic data authentication is performed, this element should be requested
by the card in CDOL2 data.
46 ICC PIN ENCIPHERMENT PRIVATE KEY

ICC private key part of the ICC PIN Encipherment public/private key pair used to decipher the
enciphered PIN.
By default, the D-PAS application uses the DDA ICC Public/ICC private key pair.
The issuer may use a dedicated ICC Public/ICC private key pair through ACO.
Format: Binary, up to 256 bytes.
47 ICC PIN ENCIPHERMENT PUBLIC KEY CERTIFICATE

ICC PIN Encipherment Public Key certified by the issuer.
48 ICC PIN ENCIPHERMENT PUBLIC KEY EXPONENT

ICC PIN Encipherment Public Key exponent used for PIN encipherment when the ICC PIN
Encipherment Public Key is used.
49 ICC PIN ENCIPHERMENT PUBLIC KEY REMAINDER

Remaining digits of the ICC PIN Encipherment Public Key Modulus.
50 ICC PRIVATE KEY

ICC private key part of the ICC public/private key pair used for offline dynamic data
authentication (DDA, CDA).
It may also used for Offline Enciphered PIN if the issuer doesn’t specify a different key.
Format: Binary, up to 256 bytes.
51 ICC PUBLIC KEY CERTIFICATE

ICC Public Key certified by the issuer.
52 ICC PUBLIC KEY EXPONENT

ICC Public Key exponent used for the verification of the Signed Dynamic Application Data.
53 ICC PUBLIC KEY REMAINDER

Remaining digits of the ICC Public Key Modulus.
54 ICC UNPREDICTABLE NUMBER

Time-variant number generated by the ICC, sent in the GET CHALLENGE response to the
terminal.
55 ISSUER ACTION CODE (IACS)

ICC contains Issuer Action Codes used by the terminal for Denial, Default, and Online during
the Terminal Action Analysis.
• IAC – Default: Specifies the issuer’s conditions that cause a transaction to be declined if it
might have been approved online, but the terminal is unable to process the transaction
online.
• IAC – Denial: Specifies the issuer’s conditions that cause the decline of a transaction
without attempt to go online.
• IAC – Online: Specifies the issuer’s conditions that cause a transaction to be transmitted
online.
Table 103 - Issuer Action Code (IAC) Encoding
BYTE 1 Take action if TVR bit is set for:
1 - - - - - - - Offline data authentication was not

performed
- 1 - - - - - - SDA failed
- - 1 - - - - - ICC data missing
- - - 1 - - - - Card appears on terminal exception file
- - - - 1 - - - DDA failed
- - - - - 1 - - CDA failed
- - - - - - 0 0 RFU
1 - - - - - - - ICC and terminal have different application

versions
- 1 - - - - - - Expired application
- - 1 - - - - - Application not yet effective
- - - 1 - - - - Requested service not allowed for card

product
- - - - 1 - - - New card
- - - - - 0 0 0 RFU
1 - - - - - - - Cardholder verification was not successful
- 1 - - - - - - Unrecognized Cardholder Verification

Method (CVM)
- - 1 - - - - - PIN Try Limit Exceeded
- - - 1 - - - - PIN entry required but PIN pad not present

or not working
- - - - 1 - - - PIN entry required, PIN pad present but PIN
not entered
- - - - - 1 - - Online PIN entered
- - - - - - 0 0 RFU
1 - - - - - - - Transaction exceeds floor limit
- 1 - - - - - - Lower consecutive offline limit exceeded
- - 1 - - - - - Upper consecutive offline limit exceeded
- - - 1 - - - - Transaction selected randomly for online

processing
- - - - 1 - - - Merchant forced transaction online
- - - - - 0 0 0 RFU
BYTE 5
1 - - - - - - - Default TDOL used
- 1 - - - - - - Issuer Authentication was unsuccessful
- - 1 - - - - - Script processing failed before final

GENERATE AC
- - - 1 - - - - Script processing failed after final
GENERATE AC
- - - - 0 0 0 0 RFU
56 ISSUER APPLICATION DATA (IAD)

Contains proprietary application data to be transmitted to the issuer in an online transaction
(in the authorization request) and after transaction completion in the clearing record.
For the D-PAS application, the Issuer Application Data is the concatenation of internal card
data elements listed in the following table and Issuer Discretionary Data (IDD).
If present, the IDD allows the issuer to transmit online additional data as PDS items or tags
that are not available in the authorization request. The issuer selects those data by using
IADOL.
Table 104 - Issuer Application Data (IAD) Content
Data Element Length
Derivation Key Index (DKI) 1

Cryptogram Version Number (CVN) 1
Card Verification Results (CVR) 6
(contains profile ID, PTC, Script Counter)
Issuer Discretionary Data items listed in IADOL n
57 ISSUER APPLICATION DATA OBJECT LIST (IADOL)

IADOL data element, personalized by the issuer, indicates the contents in Issuer Application
Data.
IADOL allows the issuer to request date element such as Offline counters or IDDT items. This
adds flexibility to the application.
The following table provides a list of data objects which may be included in IADOL list.
Table 105 - Tags supported by the IADOL list
‘00C2’ Issuer Life Cycle Data 48 *

‘00C5’ Card Action Code – Denial *profile-specific 2 *
‘00C6’ Card Action Code – Default *profile-specific 2 *
‘00C7’ Card Action Code – Online *profile-specific 2 *
‘00C8’ Lower Cumulative Offline Amount (LCOA) *profile-specific 6
‘00C9’ Upper Cumulative Offline Amount (UCOA) *profile-specific 6
‘00CA’ Single Transaction Amount (STA) limit *profile-specific 6
‘00CB’ Lower Consecutive Offline Limit (LCOL) *profile-specific 1
‘00CC’ Upper Consecutive Offline Limit (UCOL) *profile-specific 1
‘00CD’ Number of Consecutive Offline Transactions (NCOT) Counter 1
*profile-specific
‘00CE’ Cumulative Offline Amount Counter (COA) *global 6
‘00D1’ Offline Balance 6
‘9F34’ CVM Results 3
* The contents of IADOL can be dynamically modified using a scripted PUT DATA’ command, if
in-the-field troubleshooting is required. Issuer Life Cycle Data and profile-specific CACs are
included for this reason.
58 ISSUER AUTHENTICATION DATA

Data sent from the issuer or its proxy to the ICC for online Issuer Authentication.
Table 106 - Issuer Authentication Data Content
Byte Data Length
1-8 Authorization Response Cryptogram (ARPC) 8

9-10 Card Status Update (CSU) 2
59 ISSUER CODE TABLE INDEX

Indicates the code table according to ISO/IEC 8859-1 for displaying the Application Preferred
Name.
Format: Numeric, 1 byte
60 ISSUER COUNTRY CODE (5F28)

Indicates the country of the issuer according to ISO 3166. The terminal uses this data with
AUC to check geographic restrictions.
61 ISSUER DEFINED DATA TAGS (DF01 TO DF0A)

Issuer defined data tags (IDDT) are proprietary data tags in the range DF01 to DF0A which
are available to the issuer for non EMV use. The elements are accessible using PUT DATA and
GET DATA commands.
Format: Binary, variable length
Note: max size of IDDT data items may be implementation specific, but must not exceed 247
bytes (0xF7) bytes, in order to provide for an 8-byte secure messaging MAC. Every
implementation must provide for IDDT data items of 32 bytes (or less).
Associated with each IDDT data element is a size and access control parameter. Size and
access conditions are set at personalization time. Un-initialized IDDT elements have a size
byte of ‘00’.
Table 107 - Issuer Defined Data Tags (IDDT) Size and Access Parameters
Byte Data Length
1 Size of IDDT element 1

2 Access conditions for Read and Write. 1
Size and access conditions values are not returned when an IDDT element is accessed using
EMV GET DATA command.
Size and access conditions values are not supplied in the data field of a PUT DATA command
when writing to IDDT data elements
Access conditions are coded as follows:
Table 108 - Issuer Defined Data Tags (IDDT) Access Conditions Encoding (Byte 2)
Read Access Update Access Meaning
b8 b7 b6 b5 b4 b3 b2 b1
0 RFU
1 Prior GPO required
1 Prior offline PIN presentation
required
0 RFU
1 Secure messaging (integrity)
required
0 RFU
1 Prior offline PIN presentation
required
0 RFU
Different combinations of the above are possible; for example GPO and PIN may be required
for Read, while PIN and Secure Messaging may be required to update.
If Le in a GET DATA command addressing an IDDT is not the correct length, a 6CXX error
message is returned.
If proper access conditions have not been met, a ‘6982’ should be returned.
If the IDDT tag referenced has not been initialized (i.e., size of '00'), a ‘6A88’ is returned.
62 ISSUER DISCRETIONARY DATA

Issuer specified data relating to the application and is a part of the Issuer Application Data
(9F10). Contents of IDD are specified through the use of an ‘IADOL’ list of tagged elements
and lengths.
Examples of IDD data:
- Value stored in Offline counters
- IDDT Data items
- Application version number
63 ISSUER LIFE CYCLE DATA

D-PAS application proprietary data element that provides application version information, type
approval information and issuer specified data.
Issuer Life Cycle Data is stored at the application level and may be obtained using the GET
DATA command.
Table 109 - Issuer Life Cycle Data
Length
Data Element (bytes) Description
Version number 1 Identifies the version of D-PAS implemented

Approval ID 7 Identifier assigned by Discover before the card is submitted for
type approval
Application Issuer 20 Issuer specified data element. The contents of this data element
Life Cycle Data may be set during data preparation.
The coding of the contents of this field is not specified by Discover
but is at the discretion of the issuer. Typical data might include
- application AID
- issuer IIN or BIN
Application Code ID 20 Application provider specified data element. Parameters identify
the behavior of the application.
This data element is set during pre-personalization or coded into
the application.
The coding of the contents of this field is not specified by Discover
but is at the discretion of the application provider.
Typical data might include
- application configuration option
- PRU
- application version
- application provider ID
64 ISSUER PUBLIC KEY CERTIFICATE

Issuer Public Key certified by the DCI Certification Authority for use in offline static and
dynamic data authentication (SDA, DDA, CDA).
65 ISSUER PUBLIC KEY EXPONENT

Issuer Public Key exponent used for the verification of the Signed Static Application Data and
the ICC Public Key Certificate.
66 ISSUER PUBLIC KEY REMAINDER

Remaining digits of the Issuer Public Key Modulus.
67 ISSUER SCRIPT COUNTER

D-PAS proprietary data element representing a global counter of the number of script
commands processed since the last online authorization request. This counter is contained in
byte 2 of the PTH data element.
The right nibble is included in the Card Verification Results of the current transaction (in the
authorization request) or of the previous transaction (in the clearing record).
The Script Counter is updated for each script command successfully processed and reset after
a successful online transaction.
A configuration option (ACO B1b4) allows the issuer to specify whether successful Issuer
authentication is mandatory to reset Script counter, and if so, a bit in the CSU (B2b6) allows
the issuer to prevent the Script counter from being reset during the current transaction [thus
permitting the issuer to store a cumulative count of scripts executed, over a longer period of
time].
The Script counter will roll-over (revert to ‘00’) if the number of scripts accumulated exceeds
‘FF’.
68 ISSUER SCRIPT TEMPLATE 2

Contains proprietary issuer data for transmission to the card after the final GENERATE AC
command.
69 LANGUAGE PREFERENCE
1-4 languages stored in order of preference, each represented by 2 alphabetical characters
according to ISO 639-1.
Format: Alphanumeric, 2-8 bytes.
70 LOWER CONSECUTIVE OFFLINE TRANSACTION LIMIT (LCOL)

D-PAS application proprietary data element specifying the maximum number of offline
transactions allowed for the transaction profile before a transaction is forced to go online. The
NCOT counter and LCOL limit may be profile-specific.
If the profile-specified NCOT counter has exceeded the profile-specified LCOL, the ‘Lower
Consecutive Offline Transaction limit exceeded’ bit of CVR is set (Byte 5, bit 5).
71 LOWER CUMULATIVE OFFLINE AMOUNT (LCOA) LIMIT

D-PAS application proprietary data element specifying the maximum total amount of offline
transactions in the primary and secondary currencies allowed for the transaction profile before
a transaction is forced to go online. The LCOA limit may be profile-specific.
If a global COA has exceeded the profile-specified LCOA limit, the ‘Lower Cumulative Offline
Transaction Amount limit exceeded’ bit of CVR is set.
72 NUMBER OF CONSECUTIVE OFFLINE TRANSACTIONS (NCOT)

D-PAS proprietary data element representing a profile-specific counter of consecutive offline
transactions that have occurred for that card application since the last time a transaction went
online.
NCOT is used to perform card velocity checking.
NCOT is initialized to zero. Incremented by 1 each time a transaction is completed offline.
Optionally: Reset to zero when a transaction is online approved by issuer, regardless of the
presence and validity of Issuer Authentication Data.
By default: Reset to zero when a transaction is online approved by issuer, Issuer

Authentication is performed and successful, and appropriate CSU bit is set.
The value of the profile-specific NCOT may be sent to the issuer as part of the Issuer
Application Data, if included in the IADOL list. If contained in Issuer application Data, and the
appropriate configuration item is set, the NCOT may also be included in the Application
Cryptogram.
73 OFFLINE BALANCE
D-PAS application proprietary data element specifying the amount of offline spending
available for the application/transaction profile.
The value of Offline Balance may be obtained from the application using the GET DATA
command, if allowed by the Application Configuration Options.
Offline balance = UCOA – COA
74 PROCESSING OPTIONS DATA OBJECTS LIST (PDOL)

Contains a list of terminal resident data objects (tags and lengths) needed by the card
application in processing the GET PROCESSING OPTIONS command.
75 PDOL-CHECK ENTRY
PDOL-Check Entry is an element in the PDOL-Check Table array. It describes the check
condition and action to take in the PDOL-check mechanism. Refer to Appendix C for a full
description of each of the fields.
76 PDOL-CHECK TABLES (DECLINE, PROFILE, ONLINE)

If PDOL check mechanism is supported, the issuer specifies conditions to decline a
transaction, to processed it online, or to select the transaction profile through 3 tables ‘PDOL-
check tables (Decline, Profile, or Online) during the GET PROCESSING OPTIONS processing:
PDOL – Denial: Specifies the issuer’s conditions that cause a transaction to be declined during
the 1st Generate AC command.
PDOL – Online: Specifies the issuer’s conditions that cause a transaction to be transmitted
online. If a transaction is forced online by PDOL processing, all standard CRM processing is
bypassed and if terminal is unable to go online, the transaction is automatically declined.
PDOL - Profile: Select a specific ‘Transaction Profile’ with profile-specific AIP, AFL, and values
for CRM elements.
77 PIN TRY COUNTER (PTC)

Global counter indicating the number of PIN tries remaining.
The value of the PIN Try Counter may be obtained from the application using the GET DATA
command. The issuer may restrict access rights to PTC until after a GET PROCESSING
Command has been successfully performed (Configuration item in ACO).
The right nibble of PTC is included in the Card Verification Results.
Initial value is set by the issuer at personalization time.
Decremented by 1 each time an incorrect PIN is entered. Reset to the PIN Try Limit when the
correct PIN is entered or when the PIN is changed or unblocked by the issuer.
78 PIN TRY LIMIT

D-PAS application proprietary data element indicating the issuer-specified maximum number
of consecutive incorrect PIN entries allowed.
79 PREVIOUS TRANSACTION HISTORY (PTH)

D-PAS application proprietary data element used to store in non-volatile memory information
about the previous transactions. Used in PDOL-check mechanism and Card Risk Management.
This data item is not available externally.
During the Card risk management process, all information stored in the PTH must be
transferred into the CVR, and may then force a transaction to be declined or performed
online.
Table 110 - Previous Transaction History (PTH) Encoding
BYTE 1
0 0 - - - - - - RFU
1 - - - - - Unable to go online last transaction
- - - 1 - - - - ‘Go on-line next transaction’ was set (New Card, or bit set
in CSU of last transaction)
Note: If an issuer wishes to send the first transaction of a
new card online, then it is recommended to issue the
application personalized with PTH B1b5 = '1' and CAC-
Online B1b3 of = '1'.
- - - - 1 - - - Issuer authentication not performed in last online
transaction
- - - - - 1 - - Issuer Authentication failed during previous transaction
- - - - - - 1 - Script received
- - - - - - - 1 Script failed
BYTE 2
X X X X X X X X Script counter (Note: Right nibble only is copied into CVR)
The contents of PTH are set and cleared under the conditions in Table 111.
Table 111 - PTH Set and Clear conditions
BYTE 1
Meaning Bit Set and Clear conditions
Unable to go online last transaction b6 Set in 2nd GENERATE AC command if (Auth

response code = Y3 or Auth response code =
Z3)
Cleared in 2nd GENERATE AC command if
(Auth response code <> Y3 and Auth response
code <> Z3)
Go on-line next transaction b5 Set in 2nd GENERATE AC command if (Auth
response code <> Y3 and Auth response code
<> Z3), valid Auth Data present and CSU B2b3
=1)
Cleared on 2nd GENERATE AC command if
code <> Z3)
Issuer authentication not b4 Set in 2nd GENERATE AC command if (Auth
performed in last online response code <> Y3 and Auth response code
transaction <> Z3) and Issuer Authentication Data is not
present).
code <> Z3)
Issuer Authentication failed during b3 Set in 2nd GENERATE AC command if (Auth
previous transaction response code <> Y3 and Auth response code
<> Z3) and (Auth Data present and issuer
authentication failed).
code <> Z3)
Script received b2 Set on receipt of Issuer scripted command
(APPLICATION BLOCK, APPLICATION UNBLOCK,
CARD BLOCK, PIN CHANGE/UNBLOCK, PUT
DATA, or UPDATE RECORD commands)
code <> Z3)
Script failed b1 Set if an Issuer scripted command fails
(APPLICATION BLOCK, APPLICATION UNBLOCK,
CARD BLOCK, PIN CHANGE/UNBLOCK, PUT
DATA, or UPDATE RECORD).
code <> Z3)
BYTE 2
Meaning Bit Set and Reset conditions
Script counter (Note: Right nibble b4-b1 Incremented on successful execution of an

only is copied into CVR) issuer scripted command (APPLICATION BLOCK,
APPLICATION UNBLOCK, CARD BLOCK, PIN
CHANGE/UNBLOCK, PUT DATA, or UPDATE
RECORD).
code <> Z3), valid Auth Data present, and CSU
B2b6 < > 1)
code <> Z3), Auth Data is not present, Partial
Chip Implementation authorization response
accepted (ACO B1b5=1), and counters are to be
reset in a Partial Chip Implementation response
(ACO B1b4 =1).
80 PROFILE RESOURCE USAGE BITMAP

The Profile resource Usage Bitmap specifies which profile-specific resources are defined in a
given transaction profile. If a PRU bit is not set, this means that the ‘Global’ (default profile
‘0’) resource shall be used in this profile.
Refer to Appendix C for a full description of each of the fields.
81 REFERENCE PIN
D-PAS application proprietary data element containing the value of the offline PIN that is
compared to a PIN entered by the cardholder.
Format: Binary, length implementation dependent.
82 SDA TAG LIST

List of tags of primitive data objects defined in the EMV specification whose value fields are to
be included in the Signed Static Application Data or ICC Public Key Certificate or ICC PIN
Encipherment Public Key Certificate.
If supported, the SDA Tag List contains only the tag of the Application Interchange Profile.
83 SECURITY COUNTERS AND LIMITS

Format: Binary
Table 112 - Security Counters and Limits
Security Length
Counter/Limit (bytes) Purpose
ATC 2 Incremented during successful processing of a GET

PROCESSING OPTIONS (GPO) command unless there is an
early exit from this command.
ATC Limit 2 When the ATC reaches the ATC limit the application is
disabled and returns an error response of ‘6985’ to all
subsequent commands, except the ‘Select’ command.
Encrypted PIN 2 Counts the number of unsuccessful offline encrypted PIN
cryptography failure decryptions occurring in the application’s lifetime.
Encrypted PIN 2 When the “Encrypted PIN cryptography failure” counter
cryptography failure limit reaches the “Encrypted PIN cryptography failure limit” the
application is disabled and returns ‘6985’ on all subsequent
commands, except the ‘Select’ command.
Failed MAC 1 Indicates the number of scripted command MACs which have
failed verification. Used to protect SMI keys
Failed MAC limit 1 Indicates the allowed number of scripted command MACs
which have failed verification. Used to protect SMI keys.
When the “Failed MAC” counter reaches the “Failed MAC
limit” the current command is aborted with a ‘6985’ error
response, and no other scripted commands will be accepted
in the current session.
Lifetime MAC 3 Indicates the total number of scripted command MACs
processed by the application.
Lifetime MAC Limit 3 Indicates the allowed total number of scripted command
MAC verifications that may be performed over the lifetime of
the application. When the “Lifetime Failed MAC” counter
reaches the “Lifetime MAC limit” the application is disabled
and returns ‘6985’ on all subsequent commands, except the
‘Select’ command.
PIN Try Counter 1 Indicates the number of PIN tries remaining.
Returned in CVR.
PIN Try Limit 1 Indicates the total number of PIN tries allowed
Script Counter 1 Indicates the total number of successful scripts processed in
one or more previous commands. For information purposes
only.
PTH Byte 2, ‘Right nibble’ returned in CVR.
(Reset during successful 2nd GENERATE AC command, if
issuer authentication data received, issuer authentication
succeeds, and CSU B2b6 is not set. If Partial Chip
Implementation response is accepted [ACO B1b5 set], and
ACO B1b4 is also set, Script counter is automatically reset on
completion of online transaction)
Session MAC 1 Indicates the number of scripted command MACs processed
by the application during the current session.
Session MAC Limit 1 Indicates the allowed total number of scripted command
Security Length
Counter/Limit (bytes) Purpose
MACs verified during the current session. When the “Session
MAC” counter reaches the “Session MAC limit” the current
command is aborted with a ‘6985’ error response, and no
other scripted commands will be accepted in the current
session.
84 SESSION KEY FOR AC (SKAC)

ICC Session Key used for Application Cryptogram Generation.
85 SESSION KEY FOR SMC (SKSMC)

ICC Session Key used for Secure Messaging for Confidentiality.
86 SESSION KEY FOR SMI (SKSMI)

ICC Session Key used for Secure Messaging for Integrity.
87 SIGNED DYNAMIC APPLICATION DATA

Dynamic digital signature generated by the card on critical application parameters for DDA or
CDA and validated by the terminal.
88 SIGNED STATIC APPLICATION DATA (SSAD)

Static digital signature generated by the issuer on critical application parameters for SDA,
personalized in the card application and validated by the terminal.
89 SINGLE TRANSACTION AMOUNT (STA) LIMIT

D-PAS application proprietary data element specifying the single amount of the transaction in
the reference currency allowed for the card application/transaction profile before a transaction
is forced to go online.
If the transaction amount has exceeded this limit, the relevant CVR bit is set.
90 ICC MASTER KEY FOR SECURE MESSAGING CONFIDENTIALITY (ICC MKSMC)

ICC Master Key for Secure Messaging Confidentiality
91 ICC MASTER KEY FOR SECURE MESSAGING INTEGRITY (ICC MKSMI)

ICC Master Key for Secure Messaging Integrity
92 TRACK 2 EQUIVALENT DATA

Contains data equivalent to Track 2 Magnetic Stripe data. Contained in Terminal file records.
Tag: 57
Format: Binary, max 19 bytes.
93 TRACK 1 DISCRETIONARY DATA

Contains data equivalent to Magnetic Stripe Track 1 discretionary data. Optionally contained
in Terminal file records.
Tag: 9F1F
Format: Alphanumeric, variable length.
94 TRANSACTION LOG ENTRY

If Transaction Logging is supported, devices that read the Transaction Log use the Log Entry
data element to determine the location (SFI) and the maximum number of Transaction Log
records
A terminal obtains this value from the SELECT response in the FCI. This data element is also
personalized outside the SELECT response, so that the application knows where to log
transactions and the maximum number of records supported in the Transaction Log file. Note:
[EMV] specifies that the transaction log file should be in an SFI between 11 and 30.
Table 113 - Transaction Log Entry Data Element format
BYTE 1
0 0 0 - - - - - RFU
- - - x x x x x SFI containing the cyclic Transaction Log file
BYTE 2
X X X X X X X X Maximum number of records in the Transaction Log file
Example:
A Log Entry Data Element (Tag 9F4D) with the following content ‘1012’ indicates that the
Transaction Log file is located in SFI 16 and contains a maximum of 18 records.
95 TRANSACTION LOG FORMAT

Identifies the content of records (tag and length) that are logged by the card application.
This value may be obtained from the application using the GET DATA command.
The Log Format is coded like a DOL, and is fixed for the D-PAS application.
Table 114 - Transaction Log Format Content
9F02 Amount, Authorized 6

5F2A Transaction Currency Code 2
9A Transaction Date 3
9F36 Application Transaction Counter (ATC) 2
9F34 CVM Results 3
9F52 Card Verification Results (CVR) - 6
(Profile ID, PTC)
9F1A Terminal Country Code 2
95 Terminal Verification Results (TVR) 5
9C Transaction Type 1
8A Authorization Response Code 2
Example:
A Log Format Data Element (tag 9F4F) with the following content
9F02065F2A029A039F36029F34039F52069F1A0295059C018A02 indicates that the
Transaction Log records have the content specified in Table 114.
96 TRANSACTION PROFILE OBJECT (TPO)

Indicates the issuer’s configuration of ‘transaction profile’ (AIP and AFL) used in Initiate
Application Processing to generate the response to the GET PROCESSING OPTIONS command.
It also configures the risk management counter limits when a profile is selected. The profile ID
is set in relevant CVR bits.
The D-PAS application shall be able to support a minimum of 3 profiles. The maximum is
limited by issuer requirement and application design.
Each Transaction Profile is given a specific ID between 0 and 15 and provides the following
resources. The presence or absence of profile-specific resources is indicated in a Profile
Resource Usage’ bitmap (PRU). Default Profile is set to 0.
Refer to Appendix C for a full description of each of the fields.
Format: Binary, 62 bytes
97 UPPER CONSECUTIVE OFFLINE TRANSACTION LIMIT (UCOL)

D-PAS application proprietary data element specifying the maximum number of offline
transactions allowed for the transaction profile before a transaction is declined after an online
transaction is unable to be performed. UCOL may be profile-specific.
If the profile-specified NCOT has exceeded this limit, the ‘Upper Consecutive Offline
Transaction limit exceeded’ bit of CVR is set during 1st Generate AC velocity checks.
98 UPPER CUMULATIVE OFFLINE AMOUNT LIMIT (UCOA)

D-PAS application proprietary data element specifying the maximum total amount of offline
transactions in the primary and secondary currencies allowed for the transaction profile before
a transaction is declined after an online transaction is unable to be performed. UCOA may be
profile-specific.
If the global COA counter has exceeded the profile-specified UCOA limit, the ‘Upper
Cumulative Offline Transaction Amount limit exceeded’ bit of CVR is set during 1st Generate
AC velocity checks.
APPENDIX C. PDOL PROCESSING MECHANISM

The D-PAS application supports the ‘Initiate Application Processing’ functionality using the
GET PROCESSING OPTIONS command as described in [EMV 4.2-3].
However, aside from the standard EMV ‘GET PROCESSING OPTIONS’ processing, the D-PAS
application performs a proprietary series of ‘PDOL-checks’, which complement (and in some
cases, accelerates) the Card Risk Management tests performed during the 1st GENERATE AC
command.
The GET PROCESSING OPTIONS command ensures that the following are performed:
begun;

(PDOL-Profile check). Note: Profile-specific CRM values are used in all subsequent
processing, including following PDOL check.

• Ensure that the D-PAS application provides to the terminal the proper
‘Application Interchange Profile’ (AIP) and a list of files that contain the D-PAS
chip card application data, to be used in processing the transaction (AFL). The
AIP and AFL may be transaction profile-specific;
• The D-PAS application shall also increment the ATC, and reset the CVR (Card
Verification Results). The application is now be in an ‘INITIALIZED’ state.
(or clearing) byte 2, bit 4 (B2b4) of the global ACO element. If this bit is set, any previously
defined PDOL-checks (Decline, Profile, and Online) are executed. If this bit is not set, the
card shall not perform any PDOL-check processing (functionality is disabled). An issuer that
chooses to not use the PDOL-check mechanism may also clear this ACO bit to thereby bypass
all PDOL check-related processing, and thus optimize transaction performances.
1 TRANSACTION PROFILES
The D-PAS application shall offer the possibility of implementing a minimum of 3 pre-
allocated Transaction Profiles. Each Transaction Profile is given a specific ID between 1
and 15 (‘0F’) and potentially provides the following resources:
PRU 1 byte
AIP 2 bytes
AFL 32 bytes
CAC Denial 2 bytes
CAC Online 2 bytes
CAC Default 2 bytes
NCOT counter 1 byte
LCOL 1 byte
UCOL 1 byte
LCOA limit 6 bytes
UCOA limit 6 bytes
STA limit 6 bytes
Total: 62 bytes
Table 115 - Transaction Profile Content

When a transaction profile is defined / personalized by the issuer, a choice is made as to
whether the profile will use profile-specific resources or the global resource defined in default
profile ‘0’. The profile-specific resources allocated for a given profile are coded into a ‘Profile
Resource Usage’ bitmap (PRU) stored in the ‘profile’ object. If a PRU bit is not set, this means
that the ‘global’ resource is used in this transaction profile.
PROFILE RESOURCE USAGE bitmap
1 Profile-specific AIP
- 1 - - - - - - Profile-specific AFL
- - 1 - - - - - Profile-specific CACs
- - - 1 - - - - Profile-specific STA limit
- - - - 1 - - - Profile-specific LCOA and UCOA limits
- - - - - 1 - - Profile-specific LCOL and UCOL limits
- - - - - - 1 - Profile-specific NCOT counter
(Note: when bit value = 0, use global NCOT
counter)
PROFILE RESOURCE USAGE bitmap
- - - - - - - 1 NCOT usage for unrecognized currencies

If b1=1 then NCOT counts only offline
transactions in which currency is not recognized.
Else:
If b1 = 0, profile-specific (or global) NCOT counts
all offline transactions, regardless of currency
code.
Table 116 - Profile Resource Usage (PRU) Encoding

Note: the maximum number of profiles is fixed at 15 (‘0F’), so that the profile number may
be coded on 4 bits in the CVR.
When a specific profile is selected (using the PDOL-Profile check mechanism), any of the
above-mentioned profile-specified limits and data are copied into the global AIP, AFL, CAC,
LCOL, UCOL, LCOA, UCOA and STA internal card data elements, and is used for subsequent
Card Risk Management (CRM) checks, performed in the current transaction.
These elements may also be individually accessed using the ‘Get Data’ command and tags in
the range ‘C5’-‘CD’. A ‘Put Data’ command referencing one of these data items directly (tags
‘C5’-‘CC’) will affect the CRM resource specified in the current profile (as specified in the PRU
bitmap). If the resource being used by the currently selected profile is defined as being
‘Global’ (relevant PRU bit set to ‘0’), the data item in ‘profile 0’ will be modified.
The COA (Cumulative Offline Amount) counter used is always a single global counter, so that
the cumulative transaction amount is always the sum of all offline amounts accepted by (all
profiles on) the card.
The NCOT (Number of Consecutive Offline Transactions) counter may be profile-specific. This
allows the issuer to differentiate between the numbers of offline transactions occurring for
different transaction types.
If indicated in the IADOL list, the IAD (Issuer Application Data) in an online authorization
request (or AAC or TC response) may contain the value of the global COA counter, and the
value of the NCOT associated with the current transaction profile.
The ARPC response code contained in the authorization response resets the profile-specified
NCOT as well as the global COA. However, profile-specific NCOT values in other profiles are
not affected unless the CSU specifies that all offline counters shall be reset. (See Appendix B.)
Use of profiles is optional; a profile that is not initialized by the issuer, and not referenced in
the PDOL-Profile checks, shall not be used. By default, profile 00 is selected by the
application, and must be initialized with default AIP, AFL, LCOA, UCOA, LCOL, UCOL, CACs,
STA. as well as the Offline counters COA and NCOT.
2 PDOL CHECK MECHANISM

During the GET PROCESSING OPTIONS command, the ICC receives terminal-resident data
elements requested in the PDOL list (tag ‘9F38’) contained in the FCI (response to select).
• Note: This PDOL and FCI might be specific to a particular ‘Alias’ (AltAID).
If ‘PDOL-checks’ are activated, the D-PAS application uses these PDOL elements and/or
certain OS-internal data elements (such as ‘AID selected’, or ‘type of APDU interface’), and/or
the value of a tagged internal card Data objects, to perform 3 types of PDOL checks. These
checks are always performed in the same sequence:
1. PDOL-Decline checks. Allow the card application to force denial of a transaction,

regardless of other bits set in the CAC-Denial array. Bit 1 of CVR byte 4 is set, and the
equivalent bit in CAC-default array is (always) set by default.
2. PDOL-Profile checks. Allow the card application to select a particular transaction profile
based on internal or terminal resident data values.
3. PDOL-Online checks. Allow the card to force a transaction online, regardless of other CRM
checks performed in GENERATE AC command.
The following Figure 37 provides a high level overview of PDOL-check processing.
Figure 37 - PDOL Checks Mechanism
DCI EMV card Chip terminal
GET PROCESSING OPTIONS

‘Machine-State’ Command
‘Machine-State’
‘SELECTED’ PDOL Data
‘SELECTED’ Determine
Determine what
what AID
AID [Alias]
[Alias] Value
was
was selected
selected by
by Terminal,
Terminal,
and
and which
which interface
interface
[contact/contactless]
[contact/contactless] isis
being
being used
used =>
=> ‘OS
‘OS Data’
Data’
Initialize
Initialize ‘global
‘global resources’
resources’
with
with default
default values
values in
in ‘profile
‘profile 0’
0’
Increment
Increment ATC,
ATC, Initialize
Initialize
CVR
CVR &CID
&CID
Process
Process all
all ‘PDOL-Decline’
‘PDOL-Decline’
table
table entries
entries
Match
Match found?
found?
Yes
No
Initiate
Initiate Application
Application
Set
Set ‘PDOL
‘PDOL forced
forced Process
Process all
all ‘PDOL-Profile’
‘PDOL-Profile’ Processing
Processing
decline’
decline’ bit
bit and
and table
table entries
entries
‘PDOL-check
‘PDOL-check ID’ ID’ in
in
CVR
CVR
Yes
Match
Match found?
found?
No
Set
Set Profile
Profile ID
ID in
in byte
byte 55
Default
Default Transaction
Transaction Profile
Profile bits
bits 1-4
1-4 ofof CVR
CVR
ID
ID == 00
Copy
Copy ‘profile-specific’
‘profile-specific’
Process
Process all
all ‘PDOL-CRM
‘PDOL-CRM ’’ resources
table resources into
into ‘global
‘global
table entries
entries resources’
resources’
Yes
Match
Match found?
found?
Set
Set ‘PDOL
‘PDOL forced
forced
No online’
online’ bit
bit and
and ‘PDOL-
‘PDOL-
check
check ID’
ID’ in
in CVR
CVR
Return
Return Profile-Specific
Profile-Specific AIP
AIP
and
and AFL
AFL
AIP, AFL
GET PROCESSING OPTIONS
Response
Set
Set ‘Machine-State’
‘Machine-State’ to
to
‘INITIALIZED’
‘INITIALIZED’
The issuer may configure up to 15 ‘PDOL checks’ of each type. Each entry in the PDOL-check
tables (Decline, Profile, or Online) specifies which data element to evaluate, as well as size
and location of reference data, the type and number of comparisons to make, the action to be
taken if match is found, and the action to be taken if match fails. A bit-mask is also provided
to enable the issuer to filter out irrelevant bit combinations. Potential actions to take are
encoded in a bit-map, and may include:
• Set values and Exit,
• Exit without setting values,
• Set values and jump to line XX,
• Do not set values and jump to line XX,
• Set values and continue processing on next line,
• Continue processing on next line.
Potential ‘Comparison’ types may include tests:
• ‘Same as’
• ‘Different than’
• ‘Equal or greater’
Reference data may be either ‘OS data’ (such as ‘AltAID’ or ‘Interface type’), any TLV item
received in PDOL data (such as ‘Amount’ or ‘Terminal Type’), or an internal (tagged) card
data element. If comparison data is found in PDOL, an offset in PDOL data and size of
reference data must be indicated. If an Internal card data is used, the tag of the data item is
provided (Note: a maximum size of 15 bytes of comparison data is allowed).
One or more ‘comparison’ values may be provided in a PDOL-check entry. Each comparison
value must be of same length as reference value and compared with the bit-masked reference
data. All potential comparisons must be performed before the check fails. If the check
succeeds, the action to be taken is specified by the PDOL-check entry. If the check fails, the
action to be taken is also specified by the PDOL-check entry.
Note: If a data element requested in PDOL is not available to the terminal, the bytes received
in PDOL data are initialized with ‘00’s. This must be taken into consideration when coding the
‘Match’ and ‘No match’ ‘action bytes’ of PDOL-check entries.
The size of PDOL-check tables varies dynamically with the number of PDOL-check entries of
each type, as well as the size and number of comparison values. The size and contents of
PDOL-check tables are specified by the issuer during Data Preparation/ Personalization, and
sufficient EEPROM must be allocated to ensure that the issuer may use up to 15 different
PDOL-check entries in each of the 3 PDOL-check arrays (Decline, Profile, and Online).
PDOL-Check Entry:
Table 117 - PDOL-Check Entry Content
Ref Data Type Bit map coding type of Reference Data to be used in 4 bits
comparisons: ‘Interface type’, ‘Alias ID’, ‘Internal Data’
(see table below)
or ‘PDOL Data’
Ref Data Size Size of Reference and Comparison data (Max: 15 4 bits
bytes)
Ref Data Offset or Tag Offset of Reference data in PDOL data or Tag of 2 bytes
Internal Data object
‘Test type’ Bit map coding type of comparison to make, either: 4 bits
Match, No match, Equal or Greater than
(see table below)
‘Result’ ‘Value’ (result) to set if Test succeeds (0-15) 4 bits
‘Match found’ Bit map coding action to take if ‘Match found’ 1 byte
(see table below)
‘Match not found’ Bit map coding action to take if ‘Match not found’ 1 byte
(see table below)
Bit mask Bit mask used to focus on specific bits in reference Ref Data Size
data. A logical ‘AND’ is performed between bit mask
(set bits you wish
and reference data before evaluating match with
to ignore to 0)
comparison values.
Number of Match values Number of comparison values of length ‘Ref Data Size’ 1 byte
[n]
Comp value 1 Comparison value 1 Ref Data Size
….. …. ….
Comp value n Comparison value n Ref Data Size
Reference Data Type + Size
Table 118 - PDOL-Check Entry, Byte 1 Encoding
1 0 0 0 - - - - Interface type (b8 = 0: contact interface, b8 = 1:

contactless)
0 1 0 0 - - - - Alias ID#
0 0 1 0 - - - - Internal Card Data item (tagged)
0 0 0 1 - - - - PDOL Data
- - - - X X X X Size of Reference Data (max 15)
‘Test type’ + Result
Table 119 - PDOL-Check Entry, Byte 4 Encoding
1 0 0 0 - - - - Never
0 1 0 0 - - - - Exact Match
0 0 1 0 - - - - No Match
0 0 0 1 - - - - Equal or Greater
0 0 0 0 - - - - Always
- - - - X X X X Value to set (Result). Note: Always ‘0’ or ‘1’ in ‘PDOL-
Decline’ and ‘PDOL-Online’ arrays
Table 120 - PDOL-Check Entry, Byte 5/6 Encoding

Action: ‘Match found’ + ‘Match not found’
1 - - - - - - - Set value to ‘Result’

1/0 0 0 0 - - - - Continue (next line)
- 1 0 0 - - - - RFU
1/0 0 1 0 - - - - Exit
1/0 0 0 1 - - - - Jump to Line (PDOL Entry) specified in b1-4
- - - - X X X X ‘Jump to’ line (entry) in PDOL-check table
‘PDOL-Checks’ array:
Table 121 - PDOL-Check Array
Name Description Size
Tag - Length ‘DF10’ ‘xx’ (xx = total length of PDOL-Decline array) 3 bytes
N Number of PDOL-Decline entries (max 15) 1 byte
PDOL-D Len1 Size of PDOL-Decline entry 1 1 byte
PDOL-D entry 1 First PDOL-Decline Table entry PDOL-A Len1
------- -------- ------
PDOL-D LenN Size of PDOL-Decline entry N 1 byte
PDOL-D entry N Last PDOL-Decline Table entry PDOL-A LenN
Tag - Length ‘DF11’ ‘yy’ (yy = total length of PDOL-Profile array) 3 bytes
N Number of PDOL-Profile entries (max 15) 1 byte
PDOL-P Len1 Size of PDOL-Profile entry 1 1 byte
PDOL-P entry 1 First PDOL-Profile Table entry PDOL-P Len1
------- -------- ------
PDOL-P LenN Size of PDOL-Profile entry N 1 byte
PDOL-P entry N Last PDOL-Decline Table entry PDOL-P LenN
Tag-Length ‘DF12’ ‘zz’ (zz = total length of PDOL-Online array) 3 bytes
N Number of PDOL-Online entries (max 15) 1 byte
PDOL-O Len1 Size of PDOL-Online entry 1 1 byte
PDOL-O entry 1 First PDOL-Online Table entry PDOL-P Len1
------- -------- ------
PDOL-O LenN Size of PDOL-Online entry N 1 byte
PDOL-O entry N Last PDOL-Online Table entry PDOL-P LenN
The following transaction flow diagram describes the sequence of events occurring during
PDOL Processing:
Figure 38 - PDOL Decline Check Flow Diagram
Copy ‘Profile 0’
PDOL- checks resources into
PDOL-Decline checks
‘Global’ profile object
Yes Application
Compare Masked
blocked?
reference data with
comparison value
3 Comparison
GPO types Yes
No No match ?
response
No
PDOL checks
Yes Evaluate ‘Match
deactivated ? Exact Match? Yes
Found’ Action code
No
No
No # of PDOL-Decline Equal or Yes

checks >0 ? Greater ?
PDOL- No
Yes
Profile
checks
Evaluate first
PDOL-check Last
Next comparison
Comparison
value
No value?
Retrieve PDOL or internal card
element ‘Reference data’ Yes
Evaluate ‘Match Not

found’ Action Code
Perform a logical ‘AND’
between reference data
and PDOL-check Bitmask
‘Set Value’
indicated in ‘Match
‘Set Value’
No Found’?
indicated in ‘Match
Yes
Not Found’?
Yes
No
Set ‘Action flag’
Set ‘Action flag’
‘Jump To’ or ‘Next’ ‘Jump To’ or

PDOL-Check Yes ‘Continue’ Action
entry indicated ?
No
Last PDOL- GPO

No
Decline entry ? response
Yes
PDOL-
enter ID of PDOL-Check
Profile ‘Action Flag’ Set CVR Byte 4 bit 1
No Yes which set ‘Action Flag’ in
checks set? ‘PDOL Decline’
CVR Byte 6, bits 5-8
Figure 39 - PDOL Profile Check Flow Diagram

PDOL-
Profile PDOL-Profile checks
Checks
PDOL-
Online
Checks
# of PDOL-Profile
checks >0 ?
Yes Compare Masked

reference data with
Evaluate First comparison value
PDOL-check
3 Comparison
types
No match ? Yes
Retrieve PDOL or internal card
element ‘Reference data’
No
Yes Evaluate ‘Match
Exact Match?
Found’ Action code
Perform a logical ‘AND’
between reference data No
and PDOL-check Bitmask Equal or Yes
Greater ?
No
Last
Next comparison
Comparison
value
No value?
Yes
‘Set Value’ Yes Copy ‘Value’ from ‘Test ‘Set Value’

indicated in ‘Match Type + Result’ byte into Yes indicated in ‘Match
Not Found’? CVR Byte 6 bits 1-4 Found’?
No
No
‘Jump To’ or
‘Jump To’ or ‘Next’
‘Continue’ Action
PDOL-Check entry
Yes indicated ?
No
Using PRU, copy all profile- PDOL-
Last PDOL-Profile Online
specific resources from new
entry, or ‘Exit’ Checks
Profile object into Global
indicated ?
No Profile object
Yes
PDOL-
Online New Profile Enter new Profile ID in
Checks No Yes
selected? CVR byte 6, bits 1-4
Figure 40 - PDOL Online Check Flow Diagram
Implementation Example
The following are multiple examples of a PDOL-Check sequence, with elements personalized in
the following way:
Alias# AID Name
0 A0000001523010 Main application: Diner’s club Credit

1 A0000002771010 Alias Payment application 1
2 A000000152XYXZ Discover Debit
3 A000000152”OTP” OTP application
Profiles (Each profile has its own AIP, AFL, FCI, Offline Limits, NCOT and CACs)
0 Credit (Default)
1 Alias Payment application 1
2 Debit
3 OTP Generation
4 Low Value Payments
Issuer Business Requirements
1 ‘Discover Debit’ and ‘Alias Payment application 1’ applications may not be accessed over
‘Contactless’ interface,
2 If ‘OTP application’ AID is selected, Terminal type must be ‘34’, and first two bytes of
‘Terminal Capabilities’ must be ‘0000’,
3 If Alias Payment application 1 AID is selected, ‘' Alias Payment application 1' transaction
profile must be used,
4 If ‘Discover Debit’ AID is selected, ‘Debit’ transaction profile must be used,
5 If ‘OTP application’ AID is selected, ‘OTP’ transaction profile must be used,
6 If transaction amount is less than USD10.00, and transaction currency is in USD, LVP (Low
Value Payment) transaction profile must be used,
7 An ATM transaction (as indicated by ‘Terminal Type’) must always go online.
All of the above business requirement may be met with the following PDOL and PDOL-check
table array:
PDOL
‘9F02069F1A025F2A029A039F35019F4002’
PDOL Check Table

‘DF102E040A4100004114000F020102094100004100200F01030D13000C4120A0FFFFFF013400000981
000041A020F00180DF113F050941000041A0000F01010941000042A0000F01020941000043A0000F010
31316000010A080FFFFFFFFFFFF010000000010000B12000644A0200FFF010840DF120D010B11000D41
A0FFFF03141516’
Tag and Length ‘DF10 2E’ PDOL-Decline checks
Number of PDOL-Decline checks ‘04’
Size of Check 1 ‘0A’

Data Type + Size ‘41’ [AltAID] [1 byte]
Data Offset ‘0000’ [N.A.]
Test type + Result ‘41’ [Exact match] [result = 1 (Abort)]
PDOL Decline Entry 1
Match found ‘14’ [Do not set value, jump to line]

[line 4]
Match not found ‘00’ [Do not set value, continue next
line]
Bit mask ‘0F’ [Last nibble of ‘OS data’ only]
Number of Match values ‘02’
Value 1 ‘01’ [If AltAID is ‘Alias Payment
application 1’]
Value 2 ‘02’ [If AltAID is ‘Discover Debit’]
Size of Check 2 ‘09’

Data Type + Size ‘41’ [AltAID] [1 byte]

Test type + Result ‘41’ [Exact match] [result = 1 (Abort)]
Match found ‘00’ [Do not set value; Continue]
Match not found ‘20’ [Do not set value; Exit]
Value 1 ‘03’ [If Alt-AID is ‘OTP’]
Size of Check 3 ‘0D’

Data Type + Size ‘13’ [PDOL data; 3 bytes]
Data Offset ‘000D’ [Terminal Type, Terminal
Capabilities]
Test type + Result ‘41’ [Exact match, result = 1 (Abort)]
Match found ‘20’ [Do not set value, Exit]
Match not found ‘A0’ [Set value; Exit]
Bit mask ‘FFFFFF’ [all bits]
Value 1 ‘340000’ [Terminal Type = 34, Capabilities
‘0000’]

Data Type + Size ‘81’ [Interface type; 1 byte]

Test type + Result ‘41’ [Exact match, result = 1 (Abort)]
Match found ‘A0’ [Set value, Exit]
Match not found ‘20’ [Do not set value; Exit]
Bit mask ‘F0’ [First nibble of ‘OS data’]
Value 1 ‘80’ [Contactless interface]
Tag and Length ‘DF11 3F ’ PDOL-Profile checks
Number PDOL-Profile checks ‘05’
Data Type + Size ‘41’ [AltAID. 1 byte]

PDOL Profile Entry 1
Test type + Result ‘41’ [Exact match, Profile number = 1]
Match not found ‘00’ [Continue]
Value 1 ‘01’ [If AltAID is ‘Alias Payment

application 1’]


Value 1 ‘02’ [If AltAID is ‘Discover Debit’]


Value 1 ‘03’ [If AltAID is ‘OTP generation’]
Size of Check 4 13
Data Type + Size 16 [PDOL data; 6 bytes]
Data Offset 0000 [First bytes in PDOL data]
Test type + Result 10 [Equal or Greater, Profile number =

0]
Match found A0 [Set value, Exit]
Match not found 80 [Set value, Continue] (LVT profile)
Bit mask FFFFFFFFFFFF [Not used]
Number of Match values 01
Value 1 000000001000 [If Amount > = 10.00]
Size of Check 5 0B
Data Type + Size 12 [PDOL data; 2 bytes]
Data Offset 0007 [Byte 7 of PDOL data]

Test type + Result 44 [Exact match, Profile number = 4]
Match not found 20 [Do not set value, Exit]
Bit mask 0FFF [Last 3 nibbles of Currency code]
Value 1 0840 [If Currency code = US Dollars]
Tag and Length ‘DF12 0D’ PDOL-Online Checks
Number PDOL-Online checks 01
Size of Check 1 0B
Data Type + Size 11 [PDOL data. 1 byte]
Data Offset 000D [i.e., Terminal Type]
Test type + Result 41 [Exact match, result = 1 (Force
PDOL ONLINE Entry 1
Online)]
Match not found 00 [Continue (Exit)]
Bit mask FF [Not used]
Value 1 14 [If Terminal type is ATM]
Value 2 15 [“““““]
Value 3 16 [“““““]
In a series of sample transactions, the following occurs:
Scenario 1
Description Tag Size in PDOL Value
Amount Authorized 9F02 06 ‘000000000999’

($9.99)
Terminal Country Code 9F1A 02 ‘0840’
Transaction Currency Code 5F2A 02 ‘0840’
Transaction Date 9A 03 ‘080607’
Terminal Type 9F35 01 ‘25’
Additional Terminal Capabilities 9F40 02 ‘0000’

Interface ‘Diners Club Credit’ AID is selected over ‘Contactless’ interface
Result Based on PDOL checks, the transaction shall proceed using the
LVP transaction profile.
Scenario 2

Interface ‘Discover Debit’ AID is selected over ‘Contactless’ interface
Result Based on PDOL checks, the transaction shall be Declined.
Scenario 3

($99.99)
Interface ‘Discover Debit’ AID is selected over ‘Contact’ interface
Result Based on PDOL checks, the transaction shall be processed using

the Debit transaction profile.
Scenario 4

($99.99)

Interface ‘Discover Debit’ AID is selected over ‘Contact’ interface

the Debit transaction profile, but shall be Forced Online.
Scenario 5

($00.00)
Interface ‘OTP Application’ AID is selected over ‘Contact’ interface

the OTP transaction profile, and a ‘One Time Password’ shall be
generated.
APPENDIX D. D-PAS APPLICATION PERSONALIZATION

During personalization of the D-PAS application, a number of decisions must be made by the
issuer concerning the value of many different data elements. These data elements will fall in
the following categories,
• EMV Parameter settings, including acceptable card usage and offline limits,
• Card and Terminal risk management parameters (IAC and CAC values),
• Use of optional functionalities, such as IDDT fields,
• Access conditions associated with file bodies or tagged data fields,
• Contents of Issuer Application Data and Transaction Log entries,
• Use and definition of AltAIDs (Alternate AIDs),
• Use and definition of Transaction Profiles; choice of Profile resources (offline limits),
• Use of PDOL-check mechanism, and definition of PDOL array checks,
• Other Application Configuration Options (such as Transaction Logging options).

D-PAS payment application personalization will use one of the following functionalities:
1. Data Preparation Template tool, which will walk the issuer through all the personalization
choices available and provide default values when appropriate. This functionality will
usually be supplied in the form of a separate software utility, which is linked with the ‘Data
Preparation’ process preceding card personalization; or
2. An EMV Common Personalization Specification (CPS) interface, which uses the commands
‘Select’, ‘Initialize Update’, ‘External authenticate’, and ‘Store data’ to load a pre-defined
set of DGIs (Data Grouping Identifiers), which contain all the personalization data required
by the card, grouped by data type.
The following sections document the interface that shall be implemented by a D-PAS-
compliant application supporting personalization by means of CPS. For the sake of clarity and
completeness, much of the following sections are extracted verbatim from [EMV CPS]
specifications. In other cases, reference to specific sections of [EMV CPS] is made.
1 DATA ELEMENTS TO BE PERSONALISED

This section specifies the data elements that are personalized for the application. The
requirements of this section apply regardless of whether the application is personalized using
EMV CPS, or another personalization method.
How data elements are personalized or pre personalized is beyond the scope of these
specifications, except when EMV CPS is used.
However, in order to function properly, the D-PAS application must have been supplied with
personalization values for a ‘Minimal set’ of data items.
The minimal set of data items is listed in Table 122.
Table 122 - Minimal set of Data items
CPS
Tag Data Element Location Length DGI
Issuer Application Data

'D0' Internal card data item 32 ‘4000’
Object List (IADOL)
'D2' CRM Country Code Internal card data item 2 ‘4000’
'D3' CRM Currency Code Internal card data item 2 ‘4000’
‘C1’ Application 4
Internal card data item ‘4000’
Configuration Options
- ATC Limit Internal card data item 2 ‘4001’
- Encrypted PIN 2 ‘4001’
cryptography failure Internal card data item
limit
- Failed MAC limit Internal card data item 1 ‘4001’
- Lifetime MAC Limit Internal card data item 3 ‘4001’
- Session MAC Limit Internal card data item 1 ‘4001’
Profile identifier (Profile ‘BF3D’
'DF20’ Default ‘Profile 0’ resources 2
0)
‘82’ AIP Default ‘Profile 0’ resources 2 ‘BF3D’
‘94’ AFL Default ‘Profile 0’ resources 32 ‘BF3D’
‘C5- CACs (Default, Denial, ‘BF3D’
Default ‘Profile 0’ resources 3x2
C7’ Online)
‘CB’ LCOL (Lower 1 ‘BF3D’
Consecutive Offline Default ‘Profile 0’ resources
Limit)
‘CC’ UCOL (Upper 1 ‘BF3D’
Consecutive Offline Default ‘Profile 0’ resources
Limit)
CPS
‘C8’ LCOA (Lower 6 ‘BF3D’

Cumulative Offline Default ‘Profile 0’ resources
Amount) limit
‘C9’ UCOA (Upper 6 ‘BF3D’
Cumulative Offline Default ‘Profile 0’ resources
Amount) limit
‘CA’ STA (Single 6 ‘BF3D’
Transaction Amount) Default ‘Profile 0’ resources
limit
- SELECT Command Var ‘9102’
Internal Data
Response (FCI)
- ICC Master 3DES Key 16 ‘8000’
for Cryptogram Internal Data
Generation
for Secure Messaging Internal Data
INTEGRITY

for Secure Messaging Internal Data
ENCRYPT
- Offline PIN Internal Data [If Offline PIN used] 8 ‘8010’

- PIN Try Limit (PTL) Internal Data [If Offline PIN used] 1 ‘8010’
'5F24' Application Expiration Terminal File records. SDA signed data. 3 ‘0203’
Date
'5A' Application Primary Terminal File records. SDA signed data. Var. ‘0203’
Account Number (PAN)
'8C' Card Risk Terminal File records. SDA signed data. Var ‘0203’
Management Data
Object List 1 (CDOL1)
'8D' Card Risk Terminal File records. SDA signed data. Var. ‘0203’
Management Data
'8E' Cardholder Verification Terminal File records. SDA signed data. Var. ‘0203’
Method (CVM) List
'9F0D' Issuer Action Code Terminal File records. SDA signed data. 5 ‘0203’
(IAC) Default
'9F0E' Issuer Action Code Terminal File records. SDA signed data. 5 ‘0203’
(IAC) Denial
'9F0F' Issuer Action Code Terminal File records. SDA signed data. 5 ‘0203’
(IAC) Online
'5F28' Issuer Country Code Terminal File records. SDA signed data. 2 ‘0203’
'90' Issuer Public Key (IPK) If SDA, DDA, CDA, or Offline Enciphered PIN is Var. ‘0201
Certificate supported
CPS
'9F32' IPK Exponent If SDA, DDA, CDA, or Offline Enciphered PIN is 1 or 3 ‘0202’
supported
'92' IPK Remainder If SDA, DDA, CDA, or Offline Enciphered PIN is Var. ‘0202’
supported and entire IPK does not fit in IPK
Certificate
'8F' Certificate Authority If SDA, DDA, CDA, or Offline Enciphered PIN is 1 ‘0202’
Public Key Index supported
'9F47' ICC Public Key If DDA, CDA, or Offline Enciphered PIN using ICC 1 or 3 ‘0202’
Exponent Public Key is supported
'9F48' ICC Public Key If DDA, CDA, or Offline Enciphered PIN using ICC Var ‘0202’
Remainder Public Key is supported and entire ICC PK does not
fit in ICC PK Certificate
'9F49' DDOL If DDA or CDA is supported 3 ‘0202’
'9F2E' ICC PIN Encipherment If Offline Enciphered PIN using ICC PIN Var. ‘0202’
Public Key Exponent Encipherment Public Key is supported
'9F2F' ICC PIN Encipherment If Offline Enciphered PIN using ICC PIN Var. ‘0202’
Public Key Remainder Encipherment Public Key is supported and entire
ICC PIN Encipherment PK does not fit in ICC PIN
Encipherment PK Certificate
‘93’ SDA Certificate If SDA, is supported Var. ‘0203’
'9F46' ICC Public Key If DDA, CDA, or Offline Enciphered PIN using ICC Var. ‘0204’
Certificate Public Key is supported
In any of the above ‘Internal card data items’ is not personalized, and is required by the D-
PAS application processing, the D-PAS application must return a SW1SW2 of ‘6984’
(Reference data not useable). If the missing data is normally contained in Terminal file
records, the terminal will often register the event ‘ICC missing mandatory element’ bit in TVR,
and depending on IAC-Decline and TAC-decline personalization settings, may abort the
transaction.
2 EMV DATA IN RECORDS WITH SFI 1 THROUGH 10

Either before or after the personalization of the D-PAS application, the following are
determined:
The files (i.e., values for SFI) used to store EMV data.
The records (i.e., values for the record number within a file) used and the length reserved for
each record.
Some D-PAS implementations do not need to determine the organization of data in records
before personalization, since some multi application card platforms do not require a file
system and the applications may then simulate the files and records themselves.
Other implementations will need to determine the organization of data in records before
personalization. This is the case, for example, when a real file system is used to store the
records and when the file structure may not be created by the applications.
The following requirements apply to the organization of EMV records into files:
At a minimum, the D-PAS application shall support up to 2K (2048) bytes of memory to store
EMV records if the application supports the Dynamic-RSA implementer-option.
At a minimum, the D-PAS application shall support up to 1.5K (1536) bytes of memory to
store EMV records if the application does not support the Dynamic-RSA implementer-option.
It shall be an issuer-option to store the EMV records in any file with an SFI between 1 and 10
(e.g., records may be stored in SFI 1 and 2; or in SFI 1, 3, and 4; or in SFI 5, 6, 8, 9).
At a minimum, the D-PAS application shall support up to a total of 16 records for EMV data.
It shall be an issuer-option to place up to 16 records in any file with SFI between 1 and 10,
provided the total number of records is less than or equal to the maximum number of records
supported by the application (e.g., two records in file 1, three records in file 2 etc.).
It shall be an issuer-option to request records with a record length of up to 254 bytes.
In other words; in any implementation of the D-PAS application, allocation of the EMV data to
files and records may be performed in any file with an SFI between 1 to 10 and any record,
provided that:
The total memory for records needed is less than or equal to:
• 2048 (2K) bytes if the Dynamic-RSA implementer-option is supported
• 1536 (1.5K) bytes if the Dynamic-RSA implementer-option is not supported
The total number of records is less than or equal to 16
The length of records is less than or equal to 254 bytes, including the tag '70' and the length
byte(s).
Implementations may support:
• More than the minimum 2048 or 1536 bytes
• More than 16 records total in all files with SFI between 1 and 10
As previously implied, some implementations will support the above requirements without the
need to prepare the card before personalization to meet an issuer’s data organization needs
whilst other implementations will need to be customized before personalization.
3 EMV CPS
Support of the EMVCo Card Personalization Specification (CPS) is an implementer option for
D-PAS. For cards that support the CPS implementer option, the format of the Personalization
data must be consistent across implementations for an issuer to be able to personalize
different implementations with the same Personalization data. The requirements of this
section apply when the application is personalized using EMV CPS as the Personalization
method.
3.1 PERSONALIZATION COMMANDS
3.1.1 OVERVIEW
Command APDUs are defined in the [EMV CPS], Chapter 3. A typical Personalization consists
of the following commands in the sequence shown:
• Select
• Initialize Update
• External Authenticate
• Store Data
• Note: CPS-specific APDU command specifics are documented in section 5.
3.1.2 SELECT COMMAND

The SELECT command is used to select the IC card application to be personalized. Application
selection is described in [EMV 4.2-1].
The SELECT command will be issued once for each IC card application to be personalized. The
data in the FCI (the response to the SELECT command) will be changed during the
Personalization process. There is no specific requirement for it prior to Personalization, other
than the requirement to return the AID Tag (84) with length and value.
3.1.3 INITIALIZE UPDATE COMMAND

The INITIALIZE UPDATE command is the first command issued after the Personalization
device selects the application. INITIALIZE UPDATE will begin setting up the Secure Channel
Session to be used during personalization. The data to perform mutual authentication is
exchanged.
3.1.4 EXTERNAL AUTHENTICATE COMMAND

The EXTERNAL AUTHENTICATE command follows the INITIALIZE UPDATE command and is
used to authenticate the personalization device to the IC card application. EXTERNAL
AUTHENTICATE will be issued once for each secure channel initiation and shall be issued at
least once for each application to be personalized.
D-PAS applications shall support the three security levels allowed in EMV CPS:
• No security – The secure channel is established for authentication purposes only
• MAC – The secure channel is established for integrity as well as authentication

purposes
Encryption and MAC – The secure channel is established for confidentiality and integrity as
well as authentication purposes.
Note: In order to enable the ‘External authentication’ mechanism, and permit the creation of
a secure personalization channel, The D-PAS application must be ‘pre-personalized’ with 1 or
more 3DES ‘authentication’ keys, before the CPS session is initialized. How these keys are
diversified on a card-by-card basis, and how these keys are initialized in a specific card OS, is
beyond the scope of these specifications.
3.1.5 STORE DATA COMMAND

The STORE DATA command is used to send personalization data to the card application. The
data preparation process organizes the personalization data to be sent into data groupings. A
Data Grouping Identifier (DGI) identifies each data grouping. The IC card application then
uses the DGI to determine how the data grouping is to be processed.
The P1 value in the STORE DATA command header shall be ignored except for the 3 first high-
order bits, used to indicate an encrypted DGI or the last STORE DATA command.
The P2 value in the STORE DATA command header shall be ignored.
Support for a single DGI spanning two STORE DATA commands is needed to personalize a
record containing an Issuer Certificate with a CA key size of 1984-bits, and template tags that
may overflow the length of the command data field in a single STORE DATA command.
Support of multiple DGIs in a single STORE DATA command may reduce the number of
commands needed, and perhaps the personalization time. A STORE DATA command that
supports multiple DGIs is not required to also be able to span the last DGI over a second
STORE DATA command.
A single STORE DATA command may support multiple DGIs.
The DPAS application must support any single DGI spanning two STORE DATA commands.
The application need only support single-byte DGI lengths.
All tagged data elements shall be entered in the DGI in TLV format, and the application shall
accept tagged data elements in any order within the specified DGI.
3.2 DATA GROUPING RULES

Rules for the creation of data groupings are defined in EMV CPS Section 2.2.
3.3 DATA GROUPING ORDER

It is recommended that application developers allow Data Groupings to be sent to the D-PAS
application in any order. However, in some implementations there may be constraints on the
way in which the Data Groupings are ordered.
The application developer and Data Preparation must ensure that any such implementation-
specific constraints are respected.
3.4 GROUPED DATA GROUPINGS

It is recommended that application developers support any grouping of Data Groupings, with
the exception of Data Groupings identified in the version control field (VERCNTL) in the IC
Card Application Data. However, in some implementations there may be constraints on how
Data Groupings are grouped.
The application developer and Data Preparation must ensure that any such implementation-
specific constraints are respected.
The requirement column titled “Req.”, in the following tables of data elements for each DGI,
lists the requirements for each data element:
• M (Mandatory) indicates that the data element must be present.
• C (Conditional) indicates that the data element is necessary under certain conditions.
• O (Optional) indicates that the data element is optional
3.5 DGIS FOR RECORD DATA

For EMV applications, the persistent data elements stored in files with an SFI between 1 to 30
are stored in records and are retrievable with the EMV Read Record command. A record is
always the value of a Data Grouping.
During personalization, the application receives a series of STORE DATA commands

corresponding to the record values and then stores the record values in records. The
application must have the permanent memory available to store such records, using one of
the following methods:
The pre-allocation of the memory and file structure
The allocation of the memory and file structure during personalization
Data Groupings are reserved for record values for Data Grouping Identifiers in the range
‘XXYY’, where ‘XX’ indicates the SFI and ‘YY’ indicates the record number as follows:
• ‘01’<= ‘XX’ <= ‘1E’ and
• ‘01’<= ‘YY’ <= ‘FF’
‘XX’ represents the SFI where the record is stored. ‘YY’ represents the record number. This
specification does not mandate the file and record structure for the personalization of these
files.
As defined by EMV, the persistent data elements stored in files with a Short File Indicator
(SFI) between 1 to 10, are stored in records following the ‘70’ template and are retrievable
with the Read Record command. Note that the P1 value used in the Read Record command
corresponds to the ‘YY’ value in the DGI.
Also as specified by EMV, D-PAS applications, in both non personalized and personalized
states, do not interpret the data elements stored in these records but instead process the
Read Record command so that the appropriate personalized record is returned in the response
message.
3.6 FILES WITH SFI BETWEEN 1 AND 10

Table 123 illustrates the recommended organization of data elements for the D-PAS
application. The issuer defines how the data elements are organized and must be able to add
proprietary data elements, in addition to the data elements shown in the table.
Data Groupings are reserved for EMV SFI and record values in the range ‘'XXYY' where:
SFI '01'<= 'XX' <= '0A'
Record '01'<= 'YY' <= 'FF'
There are therefore ten files in which EMV records may be stored. Each file may contain up to
255 records. However, the D-PAS application should not approach these limits.
3.7 FILES WITH SFI BETWEEN11 AND 30

Data Groupings are reserved for EMV record values for Data Grouping Identifiers with a value
of 'XX'’, where:
‘SFI '0B' <= 'XX' <= '14'
‘SFI '15' <= 'XX' <= '1E'
Support of these Data Grouping Identifiers is optional. Among those Data Grouping
Identifiers, only 'XX' = '0B' is defined for D-PAS. D-PAS applications may support Data
Grouping Identifiers for records in other files in with a Short File Identifier between 11 and 30.
3.8 D-PAS RECOMMENDED DATA GROUP INDICATORS FOR RECORDS
Table 123 - DGI Summary for Record Data
DGI Description Table Encrypt Defined
'0101' SFI 1 Record 1: Track Data Table 124 No D-PAS

and Cardholder Name
'0102' SFI 1 Record 2: Track Data Table 125 No D-PAS
without Cardholder Name
'0201' SFI 2 Record 1: Data Table 126 No D-PAS
Authentication Data
'0202' SFI 2 Record 2: Data Table 127 No D-PAS
Authentication key Data
'0203' SFI 2 Record 3: Signed Static Table 128 No D-PAS
Application Data
'0204' SFI 2 Record 4: ICC Dynamic Table 129 No D-PAS
Authentication Data
'0205' SFI 2 Record 5: PIN Table 130 No D-PAS
Encipherment Data
'020n' SFI 2 Record n: Duplicate Table 131 No D-PAS
Data Authentication Data
'0301' SFI 3 Record 1: Duplicate Table 132 No D-PAS
Signed Application Data
'0302' SFI 3 Record 2: Card Risk Table 133 No D-PAS
Management Data
SFI 3 Record 3: Cardholder Table 134
'0303' Verification Method List No D-PAS
(only)
For DGIs with the first byte equal to '01' through '1E', the first byte indicates the SFI in which
the data is to be stored and the second byte indicates the record number within the SFI.
Other DGIs in this range are also supported, but the ones listed above reflect the default
record layout.
Table 124 - Data Content for DGI '0101'
Req. Tag Data Element Length Encrypt
M '57' Track 2 Equivalent Data * To 19 N/A

M '5F20' Cardholder Name 1-26 N/A
O '9F1F' Track 1 Discretionary Data Var. N/A
* This field may be padded at the end with a single hex ‘F’ to ensure whole bytes
M '57' Track 2 Equivalent Data * To 19 N/A

O '9F1F' Track 1 Discretionary Data Var. N/A
* This field may be padded at the end with a single hex ‘F’ to ensure whole bytes.
Req. Tag Data Element Condition Length Encrypt
C '90' Issuer Public Key If SDA, DDA, CDA, or Var. N/A

(IPK) Certificate Offline Enciphered PIN is
supported
C '9F32' IPK Exponent If SDA, DDA, CDA, or 1 or 3 N/A

Offline Enciphered PIN is
supported
C '92' IPK Remainder If SDA, DDA, CDA, or Var. N/A
Offline Enciphered PIN is
supported and entire IPK
does not fit in IPK
Certificate
C '8F' Certificate Authority If SDA, DDA, CDA, or 1 N/A
Public Key Index Offline Enciphered PIN is
supported
C '9F47' ICC Public Key If DDA, CDA, or Offline 1 or 3 N/A
Exponent Enciphered PIN using ICC
Public Key is supported
C '9F48' ICC Public Key If DDA, CDA, or Offline Var N/A

Remainder Enciphered PIN using ICC
Public Key is supported and
entire ICC PK does not fit in
ICC PK Certificate
C '9F49' DDOL If DDA or CDA is supported 3 N/A
C '9F2E' ICC PIN If Offline Enciphered PIN Var. N/A
Encipherment using ICC PIN
Public Key Encipherment Public Key is
Exponent supported
C '9F2F' ICC PIN If Offline Enciphered PIN Var. N/A
Encipherment using ICC PIN
Public Key Encipherment Public Key is
Remainder supported and entire ICC
PIN Encipherment PK does
not fit in ICC PIN
Encipherment PK Certificate
C '93' Signed Static If SDA is supported Var. N/A

Application Data
C '9F46' ICC Public Key If DDA, CDA, or Offline Var. N/A

Certificate Enciphered PIN using ICC
Public Key is supported
C '9F2D' ICC PIN If Offline Enciphered PIN Var. N/A

Encipherment Public using ICC PIN
Key Certificate Encipherment Public Key is
supported
Table 131 - Data Content for DGI '020n'
C '90' Issuer Public Key If DDA, CDA, or Offline Var. N/A

(IPK) Certificate Enciphered PIN using ICC Public
Key is supported and multiple
certificates are to be personalized.
C '8F' Certificate If DDA, CDA, or Offline 1 N/A
Authority Public Enciphered PIN using ICC Public
Key Index Key is supported and multiple
C '9F32 IPK Exponent If DDA, CDA, or Offline 1 or 3 N/A
' Enciphered PIN using ICC Public
Key is supported and multiple
C '92' IPK Remainder If DDA, CDA, or Offline Var. N/A
Enciphered PIN using ICC Public
Key is supported and entire IPK
does not fit in IPK Certificate and
multiple certificates are to be
personalized.
C '93' Signed Static If SDA is supported and multiple Var. N/A
Application Data certificates are to be personalized.
M '5F24' Application Expiration Date Always 3 N/A

O '5F25' Application Effective Date Optional 3 N/A
M '5A' Application Primary Account Always Var. N/A
Number (PAN)
O '5F34' Application PAN Sequence Optional 1 N/A
Number
O '9F07' Application Usage Control Optional 2 N/A
M '8C' Card Risk Management Data Always Var. N/A
M '8D' Card Risk Management Data Always Var. N/A
M '8E' Cardholder Verification If Cardholder Var. N/A

Method (CVM) List Verification is to
be performed for
any profile.
M '9F0D' Issuer Action Code (IAC) Always 5 N/A
Default
M '9F0E' Issuer Action Code (IAC) Always 5 N/A
Denial
M '9F0F' Issuer Action Code (IAC) Always 5 N/A
Online
C '5F28' Issuer Country Code 2 N/A
C '9F4A' SDA Tag List 1 N/A
NOTE: The data elements in this grouping are included in the Signed Application Data (SAD).
If updates to the Cardholder Verification Methods (CVM) List are to be made by the issuer
using Issuer Script Processing or if multiple CVM Lists are used and a single SAD is used, the
CVM List should be included in DGI 0303 rather than in DGI 0303.
NOTE: The AIP included in the Signed Application Data (SAD) is not included in the record
data because the value may change with the profile selected for the transaction.
O '9F05' Application Discretionary Data Var. N/A

O '9F0B' Cardholder Name Extended (27-45) Var. N/A
C '9F44' Application Currency Exponent 1 N/A
C '9F42' Application Currency Code 2 N/A
O '5F30' Service Code 2 N/A
M '9F08' Application Version Number 2 N/A
M '8E' Cardholder Verification Method (CVM) List Var. N/A
3.9 DGIS FOR INTERNAL APPLICATION DATA
Table 135 - DGI Summary for Internal Application Data
'4000' Card Internal Data Elements Table 136 No D-PAS
‘4001’ Security limits Table 137 No D-PAS
'4F3B' Template ‘BF3B’, Transaction Profile Objects (0- Table 140 No D-PAS
15)
'4F38' Template ‘BF38’, Currency Conversion values Table 139 No D-PAS
'4F33' Template ‘BF33’, PDOL-Decline Check Table Table 138 No D-PAS
'4F34' Template ‘BF34’, PDOL-Profile Check table Table 138 No D-PAS
'4F35' Template ‘BF41’, PDOL-Online Check table Table 138 No D-PAS
‘4F42’ Template ‘BF42’, Issuer Defined Data Tags Table 141 No D-PAS
O '9F36' Application Transaction Counter (ATC) 2 N/A

O 'D0' Issuer Application Data Object List (IADOL) 32 N/A
M 'D2' CRM Country Code 2 N/A
M 'D3' CRM Currency Code 2 N/A
C '9F4F' Log Format Var. N/A
M ‘C1’ Application Configuration Options 4 N/A
O ‘CF’ Previous Transaction History 2 N/A
M ‘C2’ Issuer Life Cycle Data 48 N/A
Table 137 - Data Content for DGI '4001' – Security limits
Length
Req Tag Data Element (bytes) Encrypt
M - ATC Limit 2 N/A

M - Encrypted PIN cryptography failure limit 2 N/A
M - Failed MAC limit 1 N/A
M - Lifetime MAC Limit 3 N/A
M - Session MAC Limit 1 N/A
DGI ‘4F33’-‘4F35’ each contains 0 or more ‘PDOL-Check’ entries, embedded in a BER-TLV

template with tag ‘BF33’-‘BF35’. The content of templates BF33-BF35 is described in the
following table.
Table 138 - Data Content for Templates 'BF33'-‘BF35’
Name Description Size [hex]
N Number of PDOL-Check entries [max 15] 1 byte

PDOL-Check Len1 Size of PDOL-Check entry 1 1 byte
PDOL-Check entry 1 First PDOL-Check Table entry PDOL-Check Len1
------- -------- ------
PDOL-Check LenN Size of PDOL-Check entry N 1 byte
PDOL-Check entry N Last PDOL-Check Table entry PDOL-Check LenN
Please refer to Appendix B for a description of the contents of each PDOL-Check array.
Template ‘BF33’ contains 1-15 ‘PDOL-Denial’ checks; Template ‘BF34’ contains 1-15 ‘PDOL-
Profile’ checks; Template ‘BF35’ contains 1-15 ‘PDOL-Online’ checks. Inclusion of DGIs ‘3F33’-
‘3F35’ is optional, if PDOL checks are not being used.
DGI ‘4F38’ contains 1 or 2 ‘Secondary Currency Conversion’ entries, embedded in a BER-TLV

template with tag ‘BF38’. Use of Secondary Currencies, and inclusion of DGI ‘4F38’ is optional.
If present, each Currency Conversion entry in template BF38 will have the following format.
Table 139 - Data Content for Template 'BF38' Entry
Byte Data Length Encrypt
1 Tag (C3 or C4) 1 N/A
2-3 Secondary Currency Code (according to ISO 4217.) 2 N/A

Conversion rate : decimal value used in a conversion N/A
algorithm to convert the Secondary Application Currency
4-5 Code to the card’s Primary Application Currency Code 2
Conversion exponent: Indicates the implied position of the N/A
6 decimal point from the left of the conversion rate 1
DGI ‘4F3B’ contains 1 or more ‘Transaction Profile’ objects, embedded in a BER-TLV template
with tag ‘BF3B’. Each ‘Transaction Profile’ object consists of the following elements,
concatenated without tags or lengths:
Table 140 - Data Content for Template 'BF3B' Entry
'DF20’-
M Profile identifier (0-15) 2 N/A
‘DF2F’
M - Profile Resource Usage (PRU) bitmap 1 N/A
O - AIP 2 N/A
O - AFL 32 N/A
O - CACs (Default, Denial, Online) 3x2 N/A
- NCOT (Number of Consecutive Offline 1
O N/A
Transactions) counter
O - LCOL (Lower Consecutive Offline Limit) 1 N/A
O - UCOL (Upper Consecutive Offline Limit) 1 N/A
O - LCOA (Lower Cumulative Offline Amount) limit 6 N/A
O - UCOA (Upper Cumulative Offline Amount) limit 6 N/A
O - STA (Single Transaction Amount) limit 6 N/A
At a minimum, ‘Profile 0’ (tag DF20) must be personalized in DGI 4F3B. The presence of other
Transaction Profile objects is Optional. At a minimum ‘Profile 0’ must define an AIP, an AFL,
and a set of CAC arrays. Use of other profile resources is optional; unused resources should
be initialized with a value of ’00..00’. Optional Profile objects 1-15 may contain any or all of
the profile resources specified above (as indicated in the PRU byte). Unused profile resources
should be initialized with the value ’00..00’.
DGI ‘4F42’ contains 1 or more IDDT (Issuer Defined Data Tag) entries, embedded in a BER-
TLV template with tag ‘BF42’. Use of IDDT tags, and inclusion of DGI ‘4F42’ is optional. If
present, each IDDT entry in template BF42 will have the following format:
Table 141 - Data Content for Template 'BF42' Entry
Lengt Encryp
Byte Data h t
1-2 Tag (DF01 – DF0A) 2 N/A
3 Size of IDDT element (Len) 1 N/A

4 Read and Write Access conditions for IDDT element 1 N/A
5 - (Len+5) Initialization value for IDDT element Len Optional
3.10 DGIS FOR COMMAND RESPONSE DATA

The only command response data needing a DGI is SELECT, This DGI is used for personalizing
the 'A5' template tag. Note that Transaction Logging requires tag '9F4D' in template tag
'BF0C' which is personalized as part of DGI '9102'.
Table 142 - DGI Summary for Command Response Data
'9102' SELECT Command Response (FCI) EMV CPS No EMV CPS

V1.0
Table 14
Note that Get Processing Options (GPO) response data for D-PAS uses DGI 'BF41' rather than
DGI '9104' as defined in EMV CPS. The values needed by the application to build the Issuer
Application Data contained in the Generate AC command response is personalized using tag
'D0' in DGI '0400'.
3.11 DGIS FOR PIN AND KEY RELATED DATA

The DGIs for PIN and Key Related Data are specified in EMV CPS. Presence is compulsory if
PIN or keys are used by the card application
DGI ‘8000’ contains the 3DES keys used by the DPAS card application. This DGI must be encrypted as it
contains confidential information.
Table 143 - Data Content for DGI ‘8000’ - 3DES keys
Tag Data Element Length Encrypt

Req (bytes
)
M - D-PAS Master Key for Cryptogram Generation 16 SKUDEK

M - D-PAS Master Key for Secure Messaging 16 SKUDEK
INTEGRITY
M - D-PAS Master Key for Secure Messaging 16 SKUDEK

ENCRYPT
DGI ‘8010’ contains the Offline PIN. This DGI must be encrypted as it contains confidential information.
Table 144 - Data Content for DGI ‘8010’ - PIN Block
Tag Data Element Length Encrypt

Req (bytes
)
M - Offline PIN block 8 SKUDEK
DGI ‘9010’ contains Offline PIN-related Data. The contents of this DGI should be as follows:
Table 145 - Data Content for DGI ‘9010’ - PIN-related data
Req Tag Data Element Length Encrypt

(bytes)
O 9F17 PIN Try Counter (PTC) 1 N/A

M - PIN Try Limit (PTL) 1 N/A
The q-1 mod p is the default convention to be used to generate the values for DGIs containing
the CRT components for a D-PAS RSA Private key [DDA or PIN Encipherment].
Presence is compulsory if key is used by the card application
C N/A ICC Modulus for DDA / PIN Encipherment Var. SKUDEK
C N/A ICC Modulus for PIN Encipherment Var. SKUDEK
Table 148 - Data Content for DDA Key data DGIs '8201' Through '8205'
C N/A CRT constant q -1 mod p Var. SKUDEK
C N/A CRT constant d mod (q-1) Var. SKUDEK
C N/A CRT constant d mod (p-1) Var. SKUDEK
C N/A CRT constant prime factor q Var. SKUDEK
C N/A CRT constant prime factor p Var. SKUDEK
Table 149 - Data Content for PIN Encipherment Key data DGIs '8301' Through '8305'
C N/A CRT constant q -1 mod p Var. SKUDEK
C N/A CRT constant d mod (q-1) Var. SKUDEK
C N/A CRT constant d mod (p-1) Var. SKUDEK
C N/A CRT constant prime factor q Var. SKUDEK
C N/A CRT constant prime factor p Var. SKUDEK
4 REQUIREMENTS FOR DATA ELEMENT VALUES

This section provides requirements on the personalization values for application data
elements.
4.1 AIP
The ‘Issuer Authentication is supported’ bit in the AIP is set to 0b to indicate that the card
supports Issuer Authentication as part of processing the 2nd Generate AC command
The application shall be personalized with at least one AIP, AFL Length, and AFL to be used by
the application. These will be defined in the default ‘Profile 0’.
4.2 CACS
The following requirements identify values that must be personalized in application data
elements in order to ensure D-PAS is compliant with CCD.
The following bits in the CAC-Online shall be personalized to the value 1b (for CCD
compliance):
• Go Online On Next Transaction Was Set
• Last Online Transaction Not Completed
• Cumulative Offline Amount Lower Limit Exceeded
• Number of Consecutive Offline Transactions Lower Limit Exceeded
The following bits in the CAC-Default shall be personalized to the value 1b (for CCD
compliance):
• Cumulative Offline Amount Upper Limit Exceeded
• Number of Consecutive Offline Transactions Upper Limit Exceeded
4.3 SIGNED STATIC DATA
Table 150 - Static Data to Be Authenticated
Data Items Tag Reason for Inclusion
AIP '82' Omission allows attacker to avoid or alter offline data

authentication and may allow alteration to terminal risk
management and cardholder verification
Application Effective '5F25' Omission allows use of card beyond its authorized time window
Date
Application Expiration '5F24' Omission allows use of card beyond its authorized time window
Date
Application Usage '9F07' Omission may allow attacker to avoid usage restrictions of card
Control
Data Items Tag Reason for Inclusion
CDOL1 if card '8C' Omission for CDA-capable applications may allow attacker to
supports CDA mislead the interpretation of the CDOL data
CDOL2 if card '8D' Omission for CDA-capable applications may allow attacker to
supports CDA mislead the interpretation of the CDOL data
CVM list '8E' Omission may allow attacker to avoid cardholder verification
Issuer Action Code- '9F0D' Omission allows attacker to alter terminal action analysis (and
Default thereby affect risk management)
Issuer Action Code- '9F0E' Omission allows attacker to alter terminal action analysis (and
Denial thereby affect risk management)
Issuer Action Code- '9F0F' Omission allows attacker to alter terminal action analysis (and
Online thereby affect risk management)
Issuer Country Code '5F28' Omission may allow attacker to avoid international restrictions
(tag 5F28)
PAN '5A' Omission allows attacker to claim a bogus card Identity in offline
transactions
PAN Sequence '5F34' Omission allows attacker to claim a bogus card Identity in offline
Number transactions
SDA Tag List '9F4A' Omission allows attacker to avoid or alter offline data
authentication and may allow alteration to terminal risk
management and cardholder verification
4.4 AFL AND RECORD DATA

The following requirements apply to the organization of those EMV records into files 1:
1
These are the minimum requirements that must be supported by any implementation of D-
PAS. It is allowed for an implementation to support more than this minimum, but issuers
should note that not all implementations may support more than the minimum.
At a minimum, the issuer shall be able to request up to 2K (2048) bytes of memory to store
EMV records for D-PAS
At a minimum, the issuer shall be able to store these bytes in any file with SFI 1-10 (for
example in SFI 1 and 2, or in SFI 1, 3, and 4; or in SFI 5, 6, 8, and 9)
At a minimum, the issuer shall be able to request up to a total of 16 records; with any
number of records in each file, provided the total number of records is less than or equal to
16 (for example 2 records in file 1, 3 records in file 2,…)
An issuer shall be able to request records of up to 254 bytes for each record.
Each record in SFI 1 through 10 begins with template tag '70' and a length byte, followed by
the TLV-coded record data.
4.5 CDOLS
CDOL1 shall contain the tags and lengths of the data elements listed in Table 93 (Appendix A)
in the order shown.
CDOL2 shall contain the tags and lengths of the data elements listed in Table 94 (Appendix A)
in the order shown.
4.6 KEYS
An expiration date is assigned to each Issuer Public Key certificate. The application’s
expiration data shall not be greater than the expiration date of the certificate.
All cards which support SDA, DDA or CDA shall be personalized with an Issuer Public Key
Certificate and a CA Public Key Index to identify the CA Public Key to use to decipher the
certificate.
In EMV, the same Issuer Public/Private Keys and Issuer PK Certificates are used for SDA, DDA
and CDA.
In all cards which support DDA or CDA, the ICC PK Certificate is personalized on the card. The
ICC public/private key data may also be used to support the Offline Enciphered PIN method of
cardholder verification described in Chapter 12, Cardholder Verification.
4.7 PREVIOUS TRANSACTION HISTORY (PTH)

The issuer has the option to personalize the ‘Go Online on Next Transaction’ bit in the PTH to
1b to cause a new card to attempt to go online.
An application shall support personalization of the PTH.
4.8 LOG ENTRY

The Log Entry data element indicates the SFI to be used for logging transaction, and the
maximum number of records to be supported in the Transaction Log file. If transactions are to
be logged, then the application needs to be able to read the contents of the Log Entry data
element.
If transactions are to be logged, then the Log Entry data element shall also be personalized
for the application in addition to the personalization of the FCI.
5 CPS COMMAND APDUS
5.1 INITIALIZE UPDATE

The following table specifies the ‘Initialize Update’ APDU command parameters
Table 151 - INITIALISE UPDATE Command APDU
Field Content Length
CLA ‘80’ 1
INS ‘50’ 1
P1 ’00’ – ‘7F’ 1
P2 ‘00’ 1
Lc Random number used in host and card 8
cryptogram generation
Le ‘00’ 1
The following command response data will be returned:
Table 152 - INITIALISE UPDATE Response Data
Field Length
KEYDATA (See Table 153) 10

Version number of the master key (KMC) 1
Identifier for Secure Channel Protocol (ALGSCP = ‘02’) 1
Sequence Counter 2
Card challenge (RCARD) 6
Card cryptogram 8
SW1 SW2 2
KEYDATA contents:
Table 153 - INITIALISE UPDATE Response, KEYDATA Content
Field Length Format
Identifier of the KMC (e.g., IIN right justified and left 6 BCD
padded with 1111b per quartet)
Chip Serial Number (CSN) 4 binary
The Key Version Number defines the key set Version Number to be used to initiate the Secure
Channel Session. If this value is zero, the default key set for the selected application shall be
used.
While implementing this feature is required, utilizing this feature is optional depending on the
personalization context (e.g., if the entity personalizing the EMV application is different from
the entity personalizing the PSE application).
If the value indicates a Key Version Number that is not present or indicates a Key Version
Number that is incomplete (i.e., the Key Version Number does not contain Key Identifiers 1, 2
and 3), a response of '6A88' shall be returned. The identifier of the KMC is part of the
response data to the INITIALIZE UPDATE command and it facilitates locating the issuer’s KMC.
3.2.5.7 The first 6 bytes of KEYDATA returned from the INITIALIZE UPDATE command are
used to identify the master key for secure messaging (KMC).
The six least significant bytes of KEYDATA are used as key diversification data. The
personalization device must use the KMC and KEYDATA to generate the KENC, the KMAC and
the KDEK for this IC card. These keys must have been placed in the IC card prior to the start
of the personalization process.
Subsequent processing must use the identifier for Secure Channel Protocol (ALGSCP) in the
response to the INITIALIZE UPDATE command to determine how to create MACs and when to
create session keys. The session keys must be calculated during processing of the INITIALIZE
UPDATE response using data from the IC card.
A pseudo-random card challenge generation algorithm in the card provides the data
preparation system with the ability to pre-compute the card challenge as opposed to being
random. This allows an off-card entity, with knowledge of the relevant Secure Channel secret
keys and the ability to track the Secure Channel Sequence Counter, to pre-compute an
authentication sequence without first communicating with the card.
The card challenge is a pseudo-random number that shall be unique to a Secure Channel
Session. A pseudo-random3 card challenge shall be generated as follows:
• The AID of the currently selected Application is padded with standard DES
padding.
• A MAC is calculated across the padded data using single DES plus final triple
DES, using the SKUMAC session key and an ICV of binary zeroes;
• The six leftmost bytes of the resultant MAC constitute the card challenge.
The personalization device must verify the card cryptogram in the response to the INITIALIZE
UPDATE command by generating a duplicate cryptogram and comparing it to the value
returned in the response.
The card cryptogram is a MAC created using key SKUENC:
MAC = RTERM (8 bytes)|| Sequence Counter (2 bytes) || RCARD (6 bytes).
If the card cryptogram does not verify correctly, personalization processing must be
terminated and a log of the process written.
If the received host challenge is identical to the concatenation of the Secure Channel
Sequence Counter of the identified Key Version Number and the card challenge (6 bytes
generated as described previously), a response of '6982' shall be returned.
For pre-computing INITIALIZE UPDATE command during the data preparation process, the
data preparation system needs to generate or to have access to the derived KENC, the KMAC
and the KDEK for each given card to be personalized.
For more information on cryptographic algorithms and mechanisms, please refer to [EMV CPS]
section 5.
5.2 EXTERNAL AUTHENTICATE COMMAND

The EXTERNAL AUTHENTICATE command follows the INITIALIZE UPDATE command and is
used to authenticate the personalization device to the IC card application.
The EXTERNAL AUTHENTICATE command will be issued once for each secure channel
initiation, and must be coded as shown in the following table:
Table 154 - EXTERNAL AUTHENTICATE Command APDU
CLA ‘84’ 1
INS ‘82’ 1
P1 Security level (see Table 155) 1
P2 00 1
Lc 10 1
Data Host cryptogram (8 bytes), C-MAC (8 bytes) 16
The host cryptogram is calculated by the personalization device. The response to the
EXTERNAL AUTHENTICATE commands consists only of SW1 SW2. Table 18 lists status
conditions that may occur, in addition to the general ones listed in ISO/IEC 7816-3.
Status conditions:
Table 155 - EXTERNAL AUTHENTICATE Status Words
6982 MAC failed verification

6985 Conditions of use not satisfied
6300 Authentication of host cryptogram failed
6800 Class not supported
If an EXTERNAL AUTHENTICATE command is received and is not preceded immediately by an

Initialize Update command that has been successfully processed, the SW1 SW2 ‘6985’ shall be
returned by the card.
If the secure messaging bit of the class byte (bit 3) is not set, a response of '6E00' shall be
returned.
The security level is determined by the SECLEV field within the PDI.
The following table applies to all commands following the EXTERNAL AUTHENTICATE
command. The security level does not apply to the EXTERNAL AUTHENTICATE command.
Table 156 - Security Level Encoding in Commands Following EXTERNAL AUTHENTICATE
b8 b7 b6 b5 b4 b3 b2 b1 Description
0 0 0 0 0 0 1 1 Encryption and MAC

0 0 0 0 0 0 0 1 MAC
0 0 0 0 0 0 0 0 No Security
No security – All subsequent commands received by the IC card application will not include
any security, i.e., no C-MAC and no encryption of the entire command data string by the
SKUENC.
MAC – All subsequent commands received by the IC card application must contain a C-MAC.
Encryption and MAC - All subsequent commands received by the IC card application will
include a C-MAC and the command data field will be encrypted by the SKUENC.
Note that the encryption specified in the EXTERNAL AUTHENTICATE command does not
impact the security specified by the value of P1 in the STORE DATA command (see next
section). If both the EXTERNAL AUTHENTICATE command and the STORE DATA command
specify encryption, the data is encrypted twice.
The host cryptogram must be created by generating a MAC using SKUENC. The data to be
MACed is = Sequence Counter (2 bytes) || RCARD (6 bytes)|| RTERM (8 bytes).
The DPAS application must verify the host cryptogram by generating a duplicate cryptogram
and comparing it to the value received in the command data field.
If the EXTERNAL AUTHENTICATE command is successful, the sequence counter shall be

incremented by 1 and processing must continue with one or more STORE DATA commands.
Note: For more information on cryptographic algorithms and mechanisms, please refer to
[EMV CPS] section 5.
5.3 STORE DATA COMMAND

The STORE DATA command is used to personalize the EMV applications. There will be one
STORE DATA command for each data grouping in the record from the data preparation
process, although not necessarily one data grouping per single STORE DATA command –
multiple DGIs may be sent in one STORE DATA command, as directed by a GROUP
Personalization Device Instruction.
This version of the STORE DATA command requires a secure channel to be established. A
security level of ‘00’ may be specified. The DGIs and data groupings used by the STORE DATA
command are dependent on the data in the input record. Field ENC in the input record lists
the identifiers of data groupings that must be encrypted.
The Store Data command must be coded as in the following table:
Table 157 - STORE DATA Command APDU
CLA ‘80’ or ‘84’ 1

INS ‘E2’ 1
P1 (see Table 158) 1
P2 Sequence number 1
Lc Length of command data (DGIs+MAC) 1
Data DGI-1 => DGI-n + 8-byte MAC (if secure Var. + 8
messaging used)
Coding of P1 in STORE DATA Command
Table 158 - STORE DATA APDU P1 Encoding
b8 b7 b6 b5-b1
1 Last chained Store Data command

0 Not Last chained Store Data command
1 1 All DGIs encrypted (under SKUDEK)
0 0 No DGI is encrypted
0 1 Application dependant
1 0 RFU
xxxx RFU
DGI-1 to DGI-n contain a triplet of ‘DGI tag’ (2), Length (1 or 3), and DGI data (Var.).
The CLA byte of the STORE DATA command must be consistent with the security level of
secure messaging set in EXTERNAL AUTHENTICATE command (CLA = ‘80’ if security level =
‘00’, otherwise CLA = ‘84’).
The version of the STORE DATA command used to personalize the IC card applications must
be coded as shown in Table above. One or more triplets (DGI, Length, Data body) may be
sent.
The following table lists the status conditions that may occur in addition to those specified in
ISO/IEC 7816-3.
Table 159 - STORE DATA APDU Response Status Words
'6A 88' Referenced data not found (Unrecognized

DGI)
'6A 80' Incorrect parameters in data field
If the final length of an intended STORE DATA command data field (data grouping(s) and
possible MAC) may be more that 255 bytes, then the DGI or grouped DGIs must be sent to
the card in multiple STORE DATA commands as follows:
• The first APDU contains a STORE DATA command according to the foregoing
table, truncated at the maximum allowable length (Lc equals 255 bytes
including possible MAC).
• The subsequent APDU contains a STORE DATA command with any remaining
data as command data, possibly again truncated at the maximum allowable
length (Lc less than or equal to 255 bytes including possible MAC).
The application is responsible for managing any DGI data that spans more than one STORE
DATA command. For the first STORE DATA command, the application will use the length of
the last (or only) DGI, and the actual length of the DGI data, to determine whether a
subsequent STORE DATA command is expected.
For subsequent STORE DATA commands, the application concatenates the segments of data
until the total length of the data equals the DGI length in the first STORE DATA command.
Any inconsistency between the total length of the data segments in the STORE DATA
commands, and the DGI length, shall cause an SW1SW2 of ‘6A80’ to be returned by the card.
The personalization device must set P2 to ‘00’ for the first STORE DATA command sent to the
IC card application. The personalization device must then increment the value of P2 by 1 for
each subsequent STORE DATA command.
If the FORMATTK field in the input record is set to ‘00’ and a DGI is listed in the ENC field in
the input record, the TK identified in the input record must be used to decrypt the data
created by the data preparation process.
After the input data is decrypted as described in section 5.5 of [EMV CPS] it must be re-
encrypted prior to sending it to the IC card as described in section [5.6 of EMV CPS]. Only the
data portion of the data grouping is encrypted. The DGI and length field are not encrypted.
If the FORMATTK field in the input record is set to ‘00’ and the encryption type for the DGI
listed in field ENC is ‘11’, decryption of data by the personalization device must be done in
ECB mode. Triple DES is used to decrypt each block.
If the FORMATTK field in the input record is set to ‘01’ and a DGI is listed in the “DGIs for TK”
field (as shown in Table 10) in the input record, the TK identified in the input record must be
used to decrypt the data created by the data preparation process. If the same DGI is listed in
the ENC field in the input record, after the input data is decrypted, it must be re-encrypted
prior to sending it to the IC card. Only the data portion of the data grouping is encrypted. The
DGI and length field are not encrypted.
If the FORMATTK field in the input record is set to ‘01’ and the CMODE field (as shown in Table
10) is set to ‘11’, decryption of data by the personalization device must be done in ECB mode.
Otherwise Triple DES is used to decrypt each block.
If a DGI is listed in the ENC field in the input record, after the input data is decrypted, it must
be re-encrypted prior to sending it to the IC card as described in the [EMV CPS]. Only the
data portion of the data grouping is encrypted. The DGI and length field are not encrypted.
If the encryption type for the DGI listed in field ENC is ‘11’, the personalization device uses
the session key SKUDEK to encrypt the data. Encryption must be done in ECB mode. Triple
DES is used to encrypt each block.
If all DGIs within STORE DATA command are encrypted the personalization device must set
b7 of P1 to 1, and b6 of P1 to 1. Based on this setting of P1, the IC card must use session key
SKUDEK to decrypt each individual DGI data in ECB mode. Triple DES is used to decrypt each
block.
If some DGIs within STORE DATA command are encrypted the personalization device must set
b7 of P1 to 0, and b6 of P1 to 1. Based on this setting of P1 the IC application must have the
knowledge of which DGIs are encrypted. The IC card must use session key SKUDEK to
decrypt each individual encrypted DGI data in ECB mode. Triple DES is used to decrypt each
block.
If the security level in the EXTERNAL AUTHENTICATE command specified MACing, the C-MAC
must be calculated by the personalization device using SKUMAC and verified by the IC card.
The padding is not sent to the IC card.
If the security level in the EXTERNAL AUTHENTICATE command specified MACing and
encryption, the C-MAC must be calculated by the personalization device using SKUMAC and the
command data field must be encrypted using SKUENC. Note that the padding added to the
data field to ensure that encryption takes place over a data size which is a multiple of 8-bytes
becomes part of the data field and must be reflected in the Lc. The IC card must decrypt the
command data field and verify the C-MAC.
If the SW1 SW2 that is returned by the IC card is ‘6A88’, the input data record for the DPAS
application must be checked for the presence of the field VERCNTL. If the Data Grouping
Identifier (DGI) that was rejected by the IC card is listed in field VERCNTL, normal processing
must continue and the C-MAC must be saved to be used in the computation of the next C-
MAC (i.e., it is inserted in beginning of the next command data body), and it is this modified
command data body that is MAC’ed, using an IV of eight ‘00’ bytes.
If the data grouping DGI is not listed in field VERCNTL, personalization processing of the IC
card application must be ended. The IC card must be rejected and an error log entry written.
5.4 LAST STORE DATA COMMAND

Last STORE DATA command in a chained sequence is indicated to the IC card application by
the setting of bit 8 of P1 to 1b by the personalization device. If the conditions to transition the
status of the application to “PERSONALIZED” are not satisfied as a result of missing DGIs or
missing data element(s), the SW1 SW2 ‘6A86’ may be returned by the application. Other
status conditions may be used and are specific to the application.
Data grouping ‘7FFF’, if present, must be retrieved from the input record and must be used as
the data to be sent to the DPAS application with the last STORE DATA command. The ORDER
field within PDI may override this rule.
If the IC card application being personalized uses DGI ‘7FFF’, there may be additional status
conditions that are specific to the application.
If required by the application and after successful completion of the personalization, the
acceptance of the Store Data command may be disabled by the application.
6 COMMAND RESPONSES
All responses to commands, whether successfully processed or not, include two status bytes,
SW1 and SW2. SW1 and SW2 are one byte long each as defined in ISO/IEC 7816-3.
Beside specific behavior defined for each command in above sections, when a personalization
device receives an SW1SW2 code different from ’9000’, ’6A88’, ‘61xx’ or ‘67xx’; it shall abort
the personalization process for the application if recovery is not possible.
APPENDIX E. EXAMPLE KEYS

The following key materials have been used in preparing the examples in this document.
Table 160 - Issuer Master Keys Used in Examples
Issuer Master Keys
DKI ‘01’
AC Gen ‘0123456789ABCDEFFEDCBA9876543210’
Script MAC ‘0123456789ABCDEFFEDCBA9876543210’
Script Encrypt ‘0123456789ABCDEFFEDCBA9876543210’
Table 161 - ICC Master Key Used in Examples

ICC Master Keys (derived from Issuer Master Key using EMV Master
Key Derivation Option A [EMV 4.2-1])
PAN ‘56123456781234567891’’
PSN ‘01’
AC Gen ‘CB45F892BCDA763EF131AE6DE0762634’
Script MAC ‘CB45F892BCDA763EF131AE6DE0762634’
Script Encrypt ‘CB45F892BCDA763EF131AE6DE0762634’
[End of Document]

D-PAS Card Specification v1.1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

D-PAS Card Specification v1.1

Uploaded by

Copyright:

Available Formats

D-PAS

DISCOVER FINANCIAL SERVICES

Issued Date: March 24, 2010

Proprietary and Confidential

THE DFS PARTIES MAKE NO REPRESENTATIONS OR WARRANTIES OF ANY KIND,

D-PAS Card Specification v1.1 Proprietary and Confidential Page 2 of 267

2 D-Payment Application Specification (D-PAS)...................................... 31

4 High-Level D-PAS Application Processing ............................................ 39

D-PAS Card Specification v1.1 Proprietary and Confidential Page 3 of 267

4.12.1 Issuer Authentication..................................................................................... 52

5 Common APDU Command Processing .................................................. 57

6 Application Commands ......................................................................... 63

D-PAS Card Specification v1.1 Proprietary and Confidential Page 4 of 267

6.5.3 Data Field Returned in the Response Message ................................................. 97

D-PAS Card Specification v1.1 Proprietary and Confidential Page 5 of 267

6.10.7 Example ..................................................................................................... 129

7 Issuer Script Command Processing .................................................... 151

8 Security, Cryptographic Algorithms and Keys .................................... 157

D-PAS Card Specification v1.1 Proprietary and Confidential Page 6 of 267

8.1.3 TC, ARQC and AAC Calculation ..................................................................... 158

D-PAS Card Specification v1.1 Proprietary and Confidential Page 7 of 267

35 CRM Currency Code ............................................................................................... 192

D-PAS Card Specification v1.1 Proprietary and Confidential Page 8 of 267

80 Profile Resource Usage Bitmap................................................................................ 209

D-PAS Card Specification v1.1 Proprietary and Confidential Page 9 of 267

D-PAS Card Specification v1.1 Proprietary and Confidential Page 10 of 267

Figure 34 - MAC Generation ..........................................................................................154

D-PAS Card Specification v1.1 Proprietary and Confidential Page 11 of 267

D-PAS Card Specification v1.1 Proprietary and Confidential Page 12 of 267

Table 34 - GET CHALLENGE Response Example................................................................99

D-PAS Card Specification v1.1 Proprietary and Confidential Page 13 of 267

Table 69 - SELECT Response Message Data Field ...........................................................135

D-PAS Card Specification v1.1 Proprietary and Confidential Page 14 of 267

Table 104 - Issuer Application Data (IAD) Content..........................................................200

D-PAS Card Specification v1.1 Proprietary and Confidential Page 15 of 267

Table 139 - Data Content for Template 'BF38' Entry........................................................252

D-PAS Card Specification v1.1 Proprietary and Confidential Page 16 of 267

1.0 Release 30 June 2009 Initial Release

D-PAS Card Specification v1.1 Proprietary and Confidential Page 17 of 267

D-PAS Card Specification v1.1 Proprietary and Confidential Page 18 of 267

o Added clarifying information regarding the use of counters and the

D-PAS Card Specification v1.1 Proprietary and Confidential Page 19 of 267

o Included the VERIFY command to correct an omission.

o Updated the section and Tables 25 and 26 to address Combined Dynamic

• Figures 10 through 17 - GENERATE AC Flow Diagrams: Updated the order of the

• Section 6.6.2 (Table 36): Typographical Error and Omission:

D-PAS Card Specification v1.1 Proprietary and Confidential Page 20 of 267

o Table 53 – Modified by replacing the values associated with the SELECTED

o Changed the term profile-specific to profile-specified.

o Changed the FCI Proprietary Template for the Application Label to

o Changed the Issuer Country Code Tag from ‘5F56’ to ‘5F28’.

• 6.13.7: Modified the Parameters, Details, and Lc of Table 76 to

• Section 6.14.2 Command APDU (paragraph 3):

o Expanded to include the Application Configuration Option (ACO) as follows:

D-PAS Card Specification v1.1 Proprietary and Confidential Page 21 of 267

o Alternate Application Identifier (added)

o B1b5: Deleted Issuer Authentication is Mandatory and inserted “Partial Chip

• Section 27 – Added for clarification: “Note: If Issuer Authentication Data is

D-PAS Card Specification v1.1 Proprietary and Confidential Page 22 of 267

o B2b2 - Typographical error: Replaced “0” | “RFU” with ‘1” | “CAC-default

• Section 57 - Issuer Application Data Object List (IADOL): Included CVM

• Section 66 - Issuer Script Counter: Expanded the section to include detail

• Section 74 - PDOL-Check Entry: Expanded the section.

• Section 78 - Previous Transaction History (PTH)