© 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP (as heir of the former spanish domestic schemes
ServiRed, Sistema 4B and EURO 6000)
All rights reserved.
Common Payment Application
Contactless Extension
CPACE
Functional Specification
CPACE for Host Card Emulation (HCE) in a Consumer Device
Version 1.0
15.03.2019
© 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP (as heir of the former spanish domestic schemes
ServiRed, Sistema 4B and EURO 6000)
All rights reserved.
Notice
This Specification has been prepared by Bancomat, Bancontact Payconiq Company,
BankAxept, Borica, girocard/SRC, Groupement des Cartes Bancaires CB, SIBS MB and
STMP (as heir of the former spanish domestic schemes ServiRed, Sistema 4B and EURO
6000) (hereinafter referred to as Cooperation) who are joint owners of the copyright therein.
Permission is hereby granted to use the document solely for the purpose of implementing the
Specification subject to the following conditions: (i) that none of the participants of the
Cooperation nor any contributor to the Specification shall have any responsibility or liability
whatsoever to any other party from the use or publication of the Specification; (ii) that one
cannot rely on the accuracy or finality of the Specification; and (iii) that the willingness of the
participants of the Cooperation to provide the Specification does not in any way convey or
imply any responsibility for any product or service developed in accordance with the
Specification and the participants of the Cooperation as well as the contributors to the
Specification specifically disclaim any such responsibility to any party.
Implementation of certain elements of this Specification may require licenses under third
party intellectual property rights, including without limitation, patent rights. The Participants of
the Cooperation and any other contributors to the Specification are not, and shall not be held
responsible in any manner for identifying or failing to identify any or all such third party
intellectual property rights. This Specification is provided "AS IS", "WHERE IS" and
"WITH ALL FAULTS", and no participant in the Cooperation makes any warranty of
any kind, express or implied, including any implied warranties of merchantability, non-
infringement of third party intellectual property rights (whether or not the Participants
of the Cooperation have been advised, have reason to know, or are otherwise in fact
aware of any information), and fitness for a particular purpose (including any errors
and omissions in the Specification).
To the extent permitted by applicable law, neither the Participants of the Cooperation nor any
contributor to the Specification shall be liable to any user of the Specification for any
damages (other than direct actual out-of-pocket damages) under any theory of law, including,
without limitation, any special, consequential, incidental, or punitive damages, nor any
damages for loss of business profits, business interruption, loss of business information, or
other monetary loss, nor any damages arising out of third party claims (including claims of
intellectual property infringement) arising out of the use of or inability to use the Specification,
even if advised of the possibility of such damages.
The Specification, including technical data, may be subject to export or import regulations in
different countries. Any user of the Specification agrees to comply strictly with all such
regulations and acknowledges that it has the responsibility to obtain licenses to export, re-
export, or import the Specification.
CPACE for Host Card Emulation Revision History Version 1.0
15.03.2019 Page i © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Revision History
Version Date Object
Draft 1.0 13.04.2017 First draft covering CPACE-HCE
1.0 12.11.2018 Updates and corrections according to ECPC discussion, and
integration of CDCVM
1.0 15.03.2019 Addition of usage limits for CDCVM cardholder verification and
cardholder confirmation, addition of implementer-optional
expiration dates for session keys, addition of a '2nd Presentment
Performed'-bit in the CVR, editorial improvements
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page ii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Table of Contents
1 Introduction ................................................................................................... 1
2 References, Abbreviations and Document Conventions ............................ 8
2.1 References ...................................................................................................... 8
2.2 Definitions ........................................................................................................ 9
2.3 Abbreviations ................................................................................................. 10
2.4 Document Conventions ................................................................................. 13
2.4.1 Notation ......................................................................................................... 13
2.4.2 Requirement Notation .................................................................................... 15
3 Overview ...................................................................................................... 16
3.1 Implementer-Options ..................................................................................... 16
3.1.1 CPA Implementer-Options ............................................................................. 16
3.1.2 Additional Implementer-Options ..................................................................... 16
3.2 Command Support Requirements.................................................................. 17
3.3 Performance Requirements ........................................................................... 17
4 General Command Information .................................................................. 18
4.1 State Machine................................................................................................ 18
4.1.1 States ............................................................................................................ 18
4.1.2 Sequence of Commands and Transitions Between States............................. 19
4.2 Command Validation ..................................................................................... 22
5 PPSE and Application Selection ................................................................. 24
5.1 Identifying and Selecting the Application........................................................ 24
5.2 Activation and Prioritisation of Digital Cards .................................................. 25
5.3 SELECT Command ....................................................................................... 26
5.3.1 Command Coding .......................................................................................... 26
5.3.2 Command Format Validation ......................................................................... 26
5.3.3 Processing ..................................................................................................... 28
5.3.3.1 SELECT PPSE .............................................................................................. 28
5.3.3.2 SELECT AID ................................................................................................. 30
6 Initiate Application Processing ................................................................... 33
6.1 Introduction .................................................................................................... 33
6.2 GET PROCESSING OPTIONS Command .................................................... 34
6.2.1 Command Coding .......................................................................................... 34
6.2.2 Command Format Validation ......................................................................... 35
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page iii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
6.2.3 Processing ..................................................................................................... 36
6.2.4 Profile Selection Table Processing ................................................................ 37
6.2.5 Profile Behaviour ........................................................................................... 44
6.2.6 Response to GPO Command ........................................................................ 44
7 Read Application Data ................................................................................. 45
7.1 Introduction .................................................................................................... 45
7.2 READ RECORD Command ........................................................................... 45
7.2.1 Command Coding .......................................................................................... 45
7.2.2 Command Format Validation ......................................................................... 45
7.2.3 Processing ..................................................................................................... 46
7.2.4 Respond to READ RECORD Command ........................................................ 46
8 First Card Action Analysis .......................................................................... 47
8.1 Communication with the Mobile Payment App ............................................... 47
8.2 First GENERATE AC Command .................................................................... 49
8.2.1 Command Coding .......................................................................................... 49
8.2.2 Command Format Validation ......................................................................... 51
8.2.3 Processing ..................................................................................................... 54
8.2.3.1 First GENERATE AC Checks ........................................................................ 54
8.2.3.2 Request for Online Authorisation of the Transaction ...................................... 73
8.2.3.3 Offline Decline of the Transaction .................................................................. 77
8.2.4 Respond to GENERATE AC Command......................................................... 77
8.2.4.1 Build Issuer Application Data (IAD) ................................................................ 78
8.2.4.2 Build Online Parameter .................................................................................. 82
8.2.4.3 Generate Application Cryptogram .................................................................. 83
8.2.4.4 Store Transaction History .............................................................................. 84
8.2.4.5 Notify Mobile Payment App............................................................................ 84
8.2.4.6 Return GENERATE AC Response ................................................................ 84
9 Second Card Action Analysis - only if IO1 is supported ........................... 86
9.1 Communication with the Mobile Payment App ............................................... 86
9.2 Data Update and Retrieval............................................................................. 87
9.3 Second GENERATE AC Command ............................................................... 88
9.3.1 Command Coding .......................................................................................... 88
9.3.2 Configure Second Card Analysis ................................................................... 93
9.3.3 Online Authorisation Completed .................................................................... 94
9.3.3.1 Issuer Authentication ..................................................................................... 94
9.3.3.2 CSU and PAD Processing ............................................................................. 96
9.3.4 Online Authorisation Not Completed ............................................................ 100
9.3.5 Application Approves Transaction (TC)........................................................ 100
9.3.6 Application Declines Transaction (AAC) ...................................................... 100
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page iv © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.3.7 Respond to GENERATE AC Command....................................................... 101
9.3.7.1 Build Issuer Application Data ....................................................................... 101
9.3.7.2 Generate Application Cryptogram ................................................................ 101
9.3.7.3 Store Transaction History ............................................................................ 102
9.3.7.4 Notify Mobile Payment App.......................................................................... 102
9.3.7.5 Return GENERATE AC Response .............................................................. 102
10 Handling of symmetric keys ..................................................................... 103
11 Data Model ................................................................................................. 105
11.1 Data of a Digital Card .................................................................................. 105
11.2 Provisioning and Update of a Digital Card ................................................... 110
12 Data Dictionary .......................................................................................... 113
12.1 AID Selected ............................................................................................... 116
12.2 AID Table .................................................................................................... 117
12.2.1 AID Entry ..................................................................................................... 117
12.3 AIP/AFL Entries ........................................................................................... 118
12.3.1 AIP/AFL Entry x ........................................................................................... 119
12.4 Amount, Authorised ..................................................................................... 120
12.5 Amount, Other ............................................................................................. 120
12.6 Application Control ...................................................................................... 120
12.7 Application Cryptogram ............................................................................... 121
12.8 Application Transaction Counter (ATC)........................................................ 121
12.9 Authorisation Response Code ..................................................................... 121
12.10 Card Status Update (CSU) .......................................................................... 122
12.11 Card Verification Results (CVR) .................................................................. 124
12.12 Cardholder CHC Limit .................................................................................. 126
12.13 Cardholder CHV Limit .................................................................................. 127
12.14 Cardholder CHV&C Control ......................................................................... 128
12.15 Cardholder Confirmation Data ..................................................................... 129
12.16 Cardholder Confirmation History .................................................................. 130
12.17 Cardholder Confirmation Timeout ................................................................ 131
12.18 Cardholder Confirmation Usage Limit .......................................................... 132
12.19 Cardholder Verification and Confirmation Status (CHV&CS) ....................... 132
12.20 Cardholder Verification Data ........................................................................ 134
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page v © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.21 Cardholder Verification Method (CVM) Results ............................................ 134
12.22 CDCVM Cardholder Verification History ...................................................... 135
12.23 CDCVM Cardholder Verification Timeout ..................................................... 136
12.24 CDCVM Cardholder Verification Usage Limit ............................................... 136
12.25 CHC Limit .................................................................................................... 137
12.26 CHV Limit .................................................................................................... 137
12.27 CHV Required for Next Transaction ............................................................. 137
12.28 CHV Required for This Transaction ............................................................. 138
12.29 Cryptogram Information Data (CID) ............................................................. 138
12.30 Default Issuer Application Data (IAD) .......................................................... 138
12.31 Dynamic Issuer Data ................................................................................... 139
12.32 GPO Input Data ........................................................................................... 139
12.33 GPO Input Data Length ............................................................................... 140
12.34 GPO Parameters ......................................................................................... 140
12.34.1 GPO Parameters x ...................................................................................... 141
12.35 Issuer Application Data (IAD) ....................................................................... 141
12.36 Issuer Authentication Data (IATD) ............................................................... 142
12.37 Issuer CHC Limit ......................................................................................... 143
12.38 Issuer CHV Limit .......................................................................................... 144
12.39 Issuer CHV&C Control ................................................................................. 146
12.40 Issuer Options Profile Control ...................................................................... 148
12.41 Issuer Options Profile Controls .................................................................... 148
12.41.1 Issuer Options Profile Control x ................................................................... 149
12.42 Key Counter ................................................................................................ 152
12.43 Key Counter Limits ...................................................................................... 152
12.44 Key Validity Number of Days ....................................................................... 153
12.45 Last CHV Date in Days ................................................................................ 154
12.46 No CVM Accumulator .................................................................................. 155
12.47 No CVM Accumulator Balance .................................................................... 155
12.48 No CVM Accumulator Control ...................................................................... 156
12.49 No CVM Accumulator Profile Control ........................................................... 156
12.50 No CVM Accumulator Profile Controls ......................................................... 157
12.50.1 No CVM Accumulator Profile Control x ........................................................ 157
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page vi © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.51 No CVM Counter ......................................................................................... 159
12.52 No CVM Counter Control ............................................................................. 159
12.53 No CVM Counter Profile Control .................................................................. 160
12.54 No CVM Counter Profile Controls ................................................................ 160
12.54.1 No CVM Counter Profile Control x ............................................................... 161
12.55 No CVM MaxAmount ................................................................................... 162
12.56 No CVM MaxNumber ................................................................................... 162
12.57 Number of Days Without CHV Limit ............................................................. 163
12.58 Online Parameter ........................................................................................ 163
12.59 PDOL Related Data ..................................................................................... 164
12.60 Previous Transaction History (PTH) ............................................................. 164
12.61 Profile Control .............................................................................................. 165
12.62 Profile Control Table .................................................................................... 165
12.62.1 Profile Control x ........................................................................................... 166
12.63 Profile ID ...................................................................................................... 167
12.64 Profile Selection Table ................................................................................. 167
12.64.1 Profile Selection Entry ................................................................................. 167
12.65 Proprietary Authentication Data (PAD) ........................................................ 172
12.66 Recent Cardholder Confirmation ................................................................. 172
12.67 Recent CDCVM Cardholder Verification ...................................................... 173
12.68 Restart Flag ................................................................................................. 173
12.69 Restart Indicator .......................................................................................... 174
12.70 Second Presentment Indicator ..................................................................... 174
12.71 Second Presentment Timeout ..................................................................... 175
12.72 Static Issuer Data ........................................................................................ 176
12.73 Terminal Country Code ................................................................................ 176
12.74 Terminal Risk Management Data................................................................. 176
12.75 Terminal Type.............................................................................................. 179
12.76 Terminal Verification Results (TVR) ............................................................. 179
12.77 Time of First Presentment............................................................................ 180
12.78 Transaction Amount..................................................................................... 180
12.79 Transaction Currency Code ......................................................................... 181
12.80 Transaction CVM ......................................................................................... 181
CPACE for Host Card Emulation Table of Contents Version 1.0
15.03.2019 Page vii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.81 Transaction Date ......................................................................................... 181
12.82 Transaction History ...................................................................................... 182
12.83 Transaction Type ......................................................................................... 183
12.84 Unpredictable Number ................................................................................. 183
12.85 UI Module Data ............................................................................................ 184
12.85.1 UI Module Data Entry x ................................................................................ 184
12.86 x Days Valid Key Counter ............................................................................ 185
Annex 1 Management of Dates in Days .................................................................. 186
CPACE for Host Card Emulation Tables Version 1.0
15.03.2019 Page viii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Tables
Table 1: Additional Implementer-Options ..................................................................... 17
Table 2: Command Support Requirements.................................................................. 17
Table 3: CPACE-HCE EMV processing States ............................................................ 18
Table 4: Sequence of Commands and State Transitions for Commands
if IO1 is not supported ................................................................................... 20
Table 5: Sequence of Commands and State Transitions for Commands
if IO1 is supported ......................................................................................... 21
Table 6: SELECT Command Message ........................................................................ 26
Table 7: GET PROCESSING OPTIONS Command Message ..................................... 34
Table 8: PDOL Related Data ....................................................................................... 34
Table 9: READ RECORD Command Message ........................................................... 45
Table 10: READ RECORD Command Reference Control Parameter ............................ 45
Table 11: First GENERATE AC Command Message .................................................... 49
Table 12: First GENERATE AC Command Reference Control Parameter ..................... 49
Table 13: First GENERATE AC Command Data without Terminal Risk
Management Data ......................................................................................... 51
Table 14: First GENERATE AC Command Data with Terminal Risk
Management Data ......................................................................................... 51
Table 15: Issuer Application Data (IAD) ......................................................................... 78
Table 16: First GENERATE AC Response Message Data Field .................................... 85
Table 17: Second GENERATE AC Command Message ............................................... 88
Table 18: Second GENERATE AC Command Reference Control
Parameter ...................................................................................................... 88
Table 19: Second GENERATE AC Command Data Field: Amounts in
CDOL2 .......................................................................................................... 89
Table 20: Second GENERATE AC Command Data Field: No Amounts in
CDOL2 .......................................................................................................... 89
Table 21: Second GENERATE AC Command Data Field: Amounts and
Proprietary Authentication Data in CDOL2 ..................................................... 90
Table 22: Second GENERATE AC Command Data Field: Proprietary
Authentication Data and No Amounts in CDOL2 ............................................ 90
Table 23: Individual Update Bits Assigned to No CVM Accumulator and
No CVM Counter ........................................................................................... 98
Table 24: Second GENERATE AC Response Message Data Field ............................. 102
CPACE for Host Card Emulation Tables Version 1.0
15.03.2019 Page ix © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Table 25: Configuration Data of a Digital Card ............................................................ 108
Table 26: Dynamic Data of a Digital Card .................................................................... 108
Table 27: Device Configuration Data of a Digital Card ................................................. 108
Table 28: Transaction Data ......................................................................................... 109
Table 29: Internal Working Variables ........................................................................... 109
Table 30: DGIs - Overview .......................................................................................... 112
Table 31: Data Items Used and/or Stored by CPACE-HCE EMV
processing ................................................................................................... 116
Table 32: Data Objects in the AID Entry ...................................................................... 118
Table 33: Application Interchange Profile (AIP) Coding ............................................... 119
Table 34: AIP/AFL Entry x Coding ............................................................................... 120
Table 35: Application Control Coding .......................................................................... 121
Table 36: Card Status Update (CSU) Coding .............................................................. 123
Table 37: Card Verification Results (CVR) Coding ...................................................... 125
Table 38: Cardholder CHV&C Control Coding ............................................................. 129
Table 39: Cardholder Confirmation History .................................................................. 130
Table 40: Cardholder Verification and Confirmation Status (CHV&CS)
Coding ......................................................................................................... 133
Table 41: CDCVM Cardholder Verification History ...................................................... 135
Table 42: Issuer Authentication Data (IATD) ............................................................... 142
Table 43: Issuer CHV&C Control Coding ..................................................................... 147
Table 44: CHV&C Parameters Coding ........................................................................ 147
Table 45: CHV&C Currency Conversion Coding ......................................................... 148
Table 46: Issuer Options Profile Control x Coding ....................................................... 150
Table 47: Issuer Options Profile Parameters ............................................................... 150
Table 48: Proprietary Issuer Options Profile Parameters ............................................. 152
Table 49: Key Counter Limits ...................................................................................... 152
Table 50: Key Validity Number of Days ....................................................................... 153
Table 51: No CVM Accumulator Control ...................................................................... 156
Table 52: No CVM Accumulator Profile Control x Coding ............................................ 158
Table 53: No CVM Counter Control Coding ................................................................. 160
Table 54: No CVM Counter Profile Control x Coding ................................................... 161
CPACE for Host Card Emulation Tables Version 1.0
15.03.2019 Page x © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Table 55: Online Parameter Coding ............................................................................ 164
Table 56: Previous Transaction History (PTH) ............................................................. 165
Table 57: Profile Control x Coding ............................................................................... 166
Table 58: Profile Selection Entry Coding ..................................................................... 171
Table 59: Comparison Blocks Coding.......................................................................... 171
Table 60: Positive and Negative Action Byte Coding ................................................... 171
Table 61: Proprietary Authentication Data (PAD) Coding ............................................ 172
Table 62: Terminal Risk Management Data................................................................. 179
CPACE for Host Card Emulation Requirements Version 1.0
15.03.2019 Page xi © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Requirements
Req C.1 Support of Profile Selection Using Card Data ................................................ 16
Req C.2 Support of AES .............................................................................................. 16
Req C.3 Supported commands .................................................................................... 17
Req C.4 Performance requirements ............................................................................ 17
Req C.5 Check first or second GENERATE AC command - only
applicable if IO1 is supported ......................................................................... 21
Req C.6 Rejection of incorrect command APDUs ........................................................ 22
Req C.7 Command validation ...................................................................................... 22
Req C.8 Validation of command case and Le .............................................................. 23
Req C.9 Support of several AIDs ................................................................................. 24
Req C.10 Support of AID Table ..................................................................................... 24
Req C.11 Supported FCI length ..................................................................................... 25
Req C.12 Activation and Prioritisation of Digital Cards .................................................. 26
Req C.13 Check P1 and P2 for SELECT command ...................................................... 26
Req C.14 Check Activation of Digital Cards ................................................................... 27
Req C.15 Build Directory Entries for the PPSE .............................................................. 28
Req C.16 Build FCI for PPSE ........................................................................................ 30
Req C.17 Positive response to the SELECT PPSE command ....................................... 30
Req C.18 AID supported check ..................................................................................... 30
Req C.19 Retrieve FCI Proprietary Template and GPO Parameters
Reference ...................................................................................................... 31
Req C.20 Build FCI ........................................................................................................ 32
Req C.21 Positive response to the SELECT command ................................................. 32
Req C.22 Supported length for PDOL Related Data ...................................................... 34
Req C.23 Retrieve GPO Parameters x from GPO Parameters Template ...................... 35
Req C.24 Check P1 and P2 for GPO command ............................................................ 35
Req C.25 Minimum valid length for PDOL Related Data ................................................ 35
Req C.26 Check length and format of PDOL Related Data ............................................ 36
Req C.27 Initialise Transaction Data and Internal Working Variables ............................ 36
Req C.28 Reset Restart Indicator .................................................................................. 36
Req C.29 Minimum size of the Profile Selection Table .................................................. 37
CPACE for Host Card Emulation Requirements Version 1.0
15.03.2019 Page xii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.30 Perform Profile Selection Table Processing ................................................... 37
Req C.31 Retrieve Profile Control .................................................................................. 44
Req C.32 Minimum number of AIP/AFL Entries supported ............................................ 44
Req C.33 Select AIP/AFL for response .......................................................................... 44
Req C.34 Format GPO Response ................................................................................. 44
Req C.35 Check P1 for READ RECORD command ...................................................... 45
Req C.36 Check P2 for READ RECORD command ...................................................... 46
Req C.37 SFI not found ................................................................................................. 46
Req C.38 Record not found ........................................................................................... 46
Req C.39 CDCVM cardholder verification supported by Mobile Payment
App ................................................................................................................ 47
Req C.40 Cardholder confirmation supported by Mobile Payment App .......................... 48
Req C.41 Notification of card action analysis completion ............................................... 48
Req C.42 Check Issuer Options Profile Control x .......................................................... 50
Req C.43 Interpretation of first GENERATE AC command data .................................... 50
Req C.44 Check P1 for GENERATE AC command ....................................................... 51
Req C.45 Check P2 for GENERATE AC command ....................................................... 52
Req C.46 Check first GENERATE AC command data length ........................................ 52
Req C.47 Check command data length at least meets the minimum length
allowed .......................................................................................................... 52
Req C.48 Retrieve and initialise Transaction Data ......................................................... 53
Req C.49 Check No CVM Accumulator Profile Control x, No CVM
Accumulator, No CVM MaxAmount and No CVM Accumulator
Control ........................................................................................................... 54
Req C.50 Check No CVM Counter Profile Control x, No CVM Counter, No
CVM MaxNumber and No CVM Counter Control ........................................... 55
Req C.51 Check Number of Days Without CHV Limit, Last CHV Date in
Days and Transaction Date ........................................................................... 55
Req C.52 Check second presentment ........................................................................... 57
Req C.53 Offline decline requested ............................................................................... 58
Req C.54 Terminal (erroneously) considers offline PIN Ok check .................................. 58
Req C.55 CHV Required for Next Transaction check .................................................... 59
Req C.56 CHV Limit exceeded check ............................................................................ 59
CPACE for Host Card Emulation Requirements Version 1.0
15.03.2019 Page xiii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.57 No CVM Accumulator check .......................................................................... 62
Req C.58 No CVM Counter check ................................................................................. 63
Req C.59 Maximum Number of Days Without CHV check ............................................. 64
Req C.60 Online PIN requested check .......................................................................... 64
Req C.61 CHV required check....................................................................................... 65
Req C.62 CDCVM cardholder verification check ........................................................... 65
Req C.63 Cardholder confirmation check ...................................................................... 69
Req C.64 Sequence of processing ................................................................................ 73
Req C.65 Add Transaction Amount to No CVM Accumulator ........................................ 73
Req C.66 Increment No CVM Counter ........................................................................... 74
Req C.67 Reset No CVM Accumulator .......................................................................... 74
Req C.68 Reset No CVM Counter ................................................................................. 75
Req C.69 Update Last CHV Date in Days ..................................................................... 76
Req C.70 Reset CHV Required for Next Transaction .................................................... 76
Req C.71 Update CVR, CID for going online ................................................................. 77
Req C.72 Update CVR, CID for offline decline ............................................................... 77
Req C.73 Sequence of processing ................................................................................ 77
Req C.74 Build Issuer Application Data (IAD) ................................................................ 78
Req C.75 Build Counters portion in the Issuer Application Data (IAD) ........................... 79
Req C.76 Build IDD in Issuer Application Data (IAD) ..................................................... 79
Req C.77 Determine No CHV End Date ........................................................................ 81
Req C.78 Build Online Parameter .................................................................................. 82
Req C.79 Generate Application Cryptogram .................................................................. 83
Req C.80 Store Transaction History .............................................................................. 84
Req C.81 Notification of card action analysis completion ............................................... 84
Req C.82 Data field in first GENERATE AC response message .................................... 84
Req C.83 Notification of card action analysis completion ............................................... 86
Req C.84 Data update and retrieval for second GENERATE AC
processing ..................................................................................................... 87
Req C.85 Interpretation of second GENERATE AC command data .............................. 88
Req C.86 Support Extension Data Length ..................................................................... 91
Req C.87 Check P1 for GENERATE AC command ....................................................... 91
CPACE for Host Card Emulation Requirements Version 1.0
15.03.2019 Page xiv © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.88 Check P2 for GENERATE AC command ....................................................... 91
Req C.89 Check second GENERATE AC command data length ................................... 91
Req C.90 Check value of Lc using Application Control and Issuer Options
Profile Control ................................................................................................ 92
Req C.91 Validation of the second GENERATE AC command data field ...................... 92
Req C.92 Use transaction data from second GENERATE AC command
data ............................................................................................................... 93
Req C.93 Processing if Authorisation Response Code <> "Y3" or "Z3" ......................... 94
Req C.94 Processing if Authorisation Response Code = "Y3" or "Z3"............................ 94
Req C.95 Check Issuer Authentication Data (IATD) ...................................................... 94
Req C.96 Perform Issuer Authentication ........................................................................ 95
Req C.97 Branch according to Issuer Authentication result ........................................... 96
Req C.98 Update of No CVM MaxAmount ..................................................................... 96
Req C.99 Update of No CVM MaxNumber .................................................................... 97
Req C.100 Update of Number of Days Without CHV Limit............................................... 97
Req C.101 Update of No CVM Accumulator and No CVM Counter ................................. 97
Req C.102 Update No CVM Accumulator ........................................................................ 98
Req C.103 Update No CVM Counter ............................................................................... 99
Req C.104 Update Last CHV Date in Days ..................................................................... 99
Req C.105 Use CSU to decide to approve or decline the transaction .............................. 99
Req C.106 Set bits when online processing not completed ........................................... 100
Req C.107 Update CVR bits and CID when approve transaction ................................... 100
Req C.108 Update CVR bits and CID when decline transaction .................................... 100
Req C.109 Sequence of processing .............................................................................. 101
Req C.110 Build IAD ..................................................................................................... 101
Req C.111 Generate Application Cryptogram ................................................................ 101
Req C.112 Store Transaction History ............................................................................ 102
Req C.113 Notification of card action analysis completion ............................................. 102
Req C.114 Data field in second GENERATE AC response message ............................ 102
Req C.115 Security of cryptographic keys ..................................................................... 103
Req C.116 Key Handling ............................................................................................... 103
Req C.117 Identification of Digital Cards ....................................................................... 105
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 1 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
1 Introduction
The EMVCo Common Payment Application Specification ([CPA]) has been designed to
support contact transactions only. According to this specification, an extension of [CPA]
defining the data elements and functionality of an application also supporting contactless
transactions for contactless cards, is called a Common Payment Application Contactless
Extension (CPACE) specification. An implementation of the functionality defined by a
CPACE specification is called a CPACE implementation.
Depending on the respective environment, i.e. the form factor of the component hosting the
CPACE implementation, the following CPACE variants are distinguished:
Environment CPACE Variant
Dual interface card (ID 1 format according to
[ISO 7810])
CPACE for Dual Interface Card
(CPACE-DIC)
Contactless only consumer device without a
cardholder interface (e.g. a contactless only
chip card in ID 1-Format or in another
format, a sticker, a key fob)
CPACE for Contactless Only Device
(CPACE-CLC)
Host Card Emulation (HCE) in a consumer
device (e.g. a mobile phone)
CPACE for HCE in Consumer Device
(CPACE-HCE)
Secure Element (SE) in a consumer device
(e.g. a mobile phone)
CPACE for SE in Consumer Device
(CPACE-SE)
This specification covers CPACE for HCE in Consumer Device (CPACE-HCE).
The following rules apply to CPACE-HCE:
CPACE-HCE transactions with a transaction amount below the CVM-Limit may be
processed without cardholder verification.
Cardholder verification is required for CPACE-HCE transactions with a transaction
amount which is greater than or equal to the CVM-Limit.
For CPACE-HCE transactions, cardholder verification may be performed with Online
PIN or a CDCVM. Cardholder verification performed with a CDCVM is called CDCVM
cardholder verification in this document.
It is out of scope for this specification, which CDCVM is used for cardholder
verification. It may be a platform authentication mechanism or a proprietary
authentication mechanism as described in [EMV CDCVM], or it may be a CDCVM
which requires verification by the issuer during online authorisation like mPIN.
CPACE-HCE transactions must be authorised online.
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 2 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
CPACE-HCE is based on the model shown in the following Figure 1.
HCE Server
Mobile Payment App
HCE SDK
Mobile Payment App Interface
HC
EServer
Interface
User Interface Module (UI Module)
Digital Card 1
Contactless Interface
Mobile Device
Digital Card 2
Figure 1: Host Card Emulation Model
The Mobile Payment App is a mobile app which has declared to the platform of the mobile
device that it implements an HCE service for payment, thus emulating one or several
payment cards. The set of data needed to emulate a payment card for HCE is called a
Digital Card.
The user (the owner, to be precise) of the mobile device is considered to be the cardholder of
the Digital Cards. The Mobile Payment App offers and controls the interface to the
cardholder, i.e. cardholder information and cardholder input. In this specification, the term
User Interface Module or UI Module is used to reference this function of the Mobile
Payment App.
The HCE SDK is software integrated in the Mobile Payment App which implements the
functions needed for Digital Card processing over the contactless interface and for Digital
Card storage and management over the Mobile Payment App interface and the HCE
Server interface. Normally, the HCE SDK supports storage and processing of several Digital
Cards.
This specification describes
the data constituting a Digital Card for CPACE-HCE and
the functionality and data to be supported by the HCE SDK for Digital Card
processing over the contactless interface, which consists of
PPSE processing and
EMV transaction processing.
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 3 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
According to this specification, the EMV transaction processing functionality to be supported
by the HCE SDK for CPACE-HCE is based on [CPA], but adapts [CPA] to support
contactless and HCE processing.
PPSE and EMV transaction processing functionality defined in this specification is referred to
as CPACE-HCE EMV processing.
In addition to cardholder verification, CPACE-HCE EMV processing supports cardholder
confirmation (sometimes also called cardholder acknowledgement). It is out of scope for this
specification and left to the issuer's decision which method is used for cardholder
confirmation. For example, an issuer may decide to use a platform authentication mechanism
for cardholder confirmation.
Two limits are used by CPACE-HCE EMV processing to determine whether cardholder
verification or cardholder confirmation is required for a transaction:
The CHV Limit is the minimum of the Issuer CHV Limit defined by the issuer and, if
applicable according to issuer settings, the Cardholder CHV Limit defined by the
cardholder.
The CHC Limit is the minimum of the CHV Limit, the Issuer CHC Limit defined by the
issuer and, if applicable according to issuer settings, the Cardholder CHC Limit
defined by the cardholder.
The issuer has the option to define the Issuer CHV Limit and/or the Issuer CHC Limit.
If defined, the Issuer CHV Limit will normally be less than or equal to the CVM-Limit. If
defined, the Issuer CHC Limit has to be less than the Issuer CHV Limit, otherwise, it will be
ignored by CPACE-HCE EMV processing.
In addition, the issuer has the option to allow the cardholder to define the Cardholder CHV
Limit (less than the Issuer CHV Limit, if defined) and/or to allow the cardholder to define the
Cardholder CHC Limit (less than the minimum of the Cardholder CHV Limit and Issuer CHC
Limit, if defined).
If the issuer has allowed the definition of Cardholder CHV Limit and/or Cardholder CHC Limit
then the Mobile Payment App has to offer this option to the cardholder, taking into account
the limits defined by the issuer.
CPACE-HCE EMV processing requires cardholder verification or cardholder confirmation
according to the following rules:
Cardholder verification is required for CPACE-HCE transactions with a transaction
amount greater than or equal to the CHV Limit.
Due to the checks performed by CPACE-HCE EMV processing it may occur that
cardholder verification is required for transactions with a transaction amount less than
the CHV Limit, even if the transaction amount is less than the CHC Limit.
If cardholder verification is not required, cardholder confirmation is required for
CPACE-HCE transactions with a transaction amount greater than or equal to the
CHC Limit and less than the CHV Limit.
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 4 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If cardholder verification is not required, CPACE-HCE transactions with a transaction
amount less than the CHC Limit may be processed without cardholder verification
and without cardholder confirmation.
These rules are based on the assumption that the method(s) to perform cardholder
verification also provide cardholder confirmation. The opposite is not considered to be true:
Method(s) to perform cardholder confirmation are not necessarily adequate for cardholder
verification.
For example, entering and confirming an mPIN also provides cardholder confirmation, while
pressing a confirm button is a method to perform cardholder confirmation but does not
provide cardholder verification.
The issuer also has the option to define that either only CDCVM cardholder verification or
both, CDCVM cardholder verification and cardholder confirmation, always require(s) a
second presentment. In this case, even if CDCVM cardholder verification or cardholder
confirmation has been performed before the transaction was started, the cardholder will be
asked to perform CDCVM cardholder verification or cardholder confirmation (again) during
the transaction. This has the advantage that the transaction amount can be confirmed by the
cardholder together with CDCVM cardholder verification or cardholder confirmation, but has
the disadvantage that a second presentment of the cardholder device is forced during the
transaction.
In addition, if the issuer does not already define that a second presentment for both, CDCVM
cardholder verification and cardholder confirmation, is forced, then the issuer has the option
to allow cardholder settings for forcing a second presentment.
If the issuer has allowed cardholder settings for forcing a second presentment, these are
restricted by the respective issuer settings:
If the issuer does not force a second presentment, then the cardholder may define
that a second presentment either only for CDCVM cardholder verification or for both,
CDCVM cardholder verification and cardholder confirmation is forced.
If the issuer forces a second presentment only for CDCVM cardholder verification,
then the cardholder may define that a second presentment for both, CDCVM
cardholder verification and cardholder confirmation is forced.
If the issuer has allowed cardholder settings for forcing a second presentment, then the
Mobile Payment App has to offer this option to the cardholder, taking into account the
restrictions defined by the issuer.
The description of CPACE-HCE EMV processing also covers interactions with the Mobile
Payment App over the Mobile Payment App interface that are necessary for PPSE and EMV
transaction processing:
PPSE processing requires information from the Mobile Payment App which Digital
Card(s) is(are) activated (and which priority order is assigned to the activated Digital
Cards).
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 5 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
EMV transaction processing requires information from the Mobile Payment App
whether and when CDCVM cardholder verification or cardholder confirmation of the
transaction has occurred on the mobile device.
EMV transaction processing provides notification to the Mobile Payment App upon
completion of card action analysis.
CPACE-HCE EMV processing is designed to work with terminals which process contactless
transactions according to [EMV A] and [EMV B] with kernel processing analogous to EMV
contact transaction processing, but without performing Offline Data Authentication and
Cardholder Verification according to [EMV 3] and with processing of Issuer Authentication
Data (IATD) only if implementer-option IO1 is supported by CPACE-HCE EMV processing
and the kernel.
The following Figure 2 shows contactless transaction processing supported by CPACE-HCE
EMV processing.
Like EMV contact transaction processing, CPACE-HCE EMV processing is driven by the
terminal. After establishing the contactless communication protocol, the terminal and
CPACE-HCE EMV processing communicate over the contactless interface through
commands sent from the terminal to CPACE-HCE EMV processing and responses received
by the terminal from CPACE-HCE EMV processing.
Note:
Currency conversion is currently not described for CPACE-HCE EMV processing
although the data elements needed for currency conversion are already defined for future
addition of this functionality.
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 6 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Entry Point
Terminal
Entry Point
Kernel
Pre-Processing
Protocol Activation
Kernel Activation
Initiate Application Processing
Read Application Data
Processing Restrictions
Card Action Analysis
Outcome Processing
Combination Selection
SELECT PPSE
Command/Response
SELECT AID
Command/Response
GET PROCESSING
OPTIONS
Command/Response
READ RECORD
Command(s)/Response(s)
GENERATE AC
Command/Response
Online Authorisation (with Online PIN, if required)
Transaction Completion
Transaction Initiation
(Amount, Transaction Type, other transaction data)
Building the Candidate List
Final Selection
Terminal Action Analysis
Floor Limit Check
CVM Selection
Mobile Device
CPACE-HCE EMV Processing
Perform first Card Action Analysis,
generate Application Cryptogram,
(see Section 8 of this specification)
Provide requested application data
(see Section 7 of this specification)
Perform Profile Selection,
provide AIP and AFL
(see Section 6 of this specification)
Provide FCI
(see Section 5.3.3.2 of this specification)
Provide list ist of supported applications
(see Section 5.3.3.1 of this specification)
Establish contactless communication protocol
(see [EMV B] and [EMV D])
IO1
implemeter-option
supported by kernel and
CPACE-HCE AND restart
requested?
Yes
Kernel
Kernel Activation
second Card Action Analysis
Outcome Processing
Combination Selection
Final Selection
GENERATE AC
Command/Response
Perform second Card Action Analysis,
generate Application Cryptogram,
(see Section 9 of this specification)
No
SELECT AID
Command/Response
Provide FCI
(see Section 5.3.3.2 of this specification)
Figure 2: Contactless Transaction Flow
CPACE for Host Card Emulation Introduction Version 1.0
15.03.2019 Page 7 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
This specification also defines requirements regarding the functionality which is to be
supported by the HCE SDK for Digital Card storage and management over the Mobile
Payment App interface and the HCE Server interface. This functionality is referred to as
Digital Card Handling in this specification.
The Mobile Payment App accesses Digital Card Handling over the Mobile Payment App
interface to modify data of the Digital Cards and to receive information on the stored Digital
Cards including information on transactions performed with Digital Cards. If cardholder
interaction is required in this context, e.g. to set the Cardholder CHC Limit, it is in the domain
of the Mobile Payment App to pass information to the cardholder and/or to request
information from the cardholder through the UI Module.
The HCE Server accesses Digital Card Handling over the HCE Server interface for
administration processes, e.g. loading of Digital Cards (also called personalisation or
provisioning), loading of cryptographic keys (also called key replenishment) and update of
Digital Card data according to issuer requirements.
The contactless interface is an external interface of the HCE SDK which has to be
implemented according to this specification to work with a contactless terminal.
The Mobile Payment App interface between HCE SDK and Mobile Payment App is an In-App
interface that is currently not described in a formal way by this specification. This
specification only defines requirements for the functionality to be made available at this
interface.
The HCE Server interface between HCE SDK and HCE Server is based on a secured Web
Service and the HCE SDK has to support push notifications (e.g. Google Cloud Messaging)
to allow the HCE Server to initiate the communication. Beyond this, this interface is currently
not described in a formal way by this specification. This specification only defines
requirements for the functionality to be made available at this interface.
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 References
15.03.2019 Page 8 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
2 References, Abbreviations and Document Conventions
2.1 References
[CPA] EMV Integrated Circuit Card Specifications for Payment Systems,
Common Payment Application Specification, Version 1.0, December
2005
Specification Bulletin 165: AES in CPA (Spec change), 1st Edition,
May 2015
Specification Bulletin 162: AES Key Derivation Erratum (Spec
Change), 1st Edition, April 2015
Specification Bulletin 145: Clarification on the Format of ICC Public
Key Exponent (Spec Change), 1st Edition, September 2014
Specification Bulletin 139: Clarification on Data Content for DGIs '3Fxx'
(Spec Change), 1st Edition, March 2014
Specification Bulletin 90: CPA Select Response for Blocked
Applications (Spec Change), 1st Edition, September 2011
Specification Bulletin 84: CPA Specification Update (Spec Change),
1st Edition, December 2010
Specification Bulletin 81: CPA Currency Conversion Accumulator
Overflow (Spec Change), 1st Edition, February 2010
Specification Update Bulletin 65: CPA Last Online Transaction Not
Completed (Spec Change), 1st Edition, May 2008
Specification Update Bulletin 64: CPA Security Limits Status Indicators
(Spec Change), 1st Edition, May 2008
Specification Update Bulletin 63: CPA Update of VLP Available Funds
(Spec Change), 3rd Edition, May 2008
Specification Update Bulletin 62: CPA Personalisation of Log Entry
with EMV-CPS (Spec Change), 2nd Edition, May 2008
Specification Update Bulletin 58: Editorial Errors in Release 1.0 of the
CPA Specification (Spec Change), 4th Edition, May 2008
Specification Update Bulletin 60: CPA Logging Data Element
Minimums (Spec Change), 2nd Edition, February 2008
Application Note 40: CPA Personalisation of Duplicate Record Data
(Clarification), 1st Edition, February 2008
Application Note 39: CPA Transaction Logging Controls in Application
Control (Clarification), 1st Edition, February 2008
Specification Update Bulletin 61: CPA Additional Check Table Error
Processing (Spec Change), 1st Edition, August 2007
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Definitions
15.03.2019 Page 9 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Specification Update Bulletin 56: CPA Corrections and Changes (Spec
Change), 2nd Edition, February 2007
[EMV 1] EMV Integrated Circuit Card Specifications for Payment Systems,
Book 1, Application Independent ICC to Terminal Interface
Requirements, Version 4.3, November 2011
[EMV 2] EMV Integrated Circuit Card Specifications for Payment Systems,
Book 2, Security and Key Management, Version 4.3, November 2011
[EMV 3] EMV Integrated Circuit Card Specifications for Payment Systems,
Book 3, Application Specification, Version 4.3, November 2011
[EMV 4] EMV Integrated Circuit Card Specifications for Payment Systems,
Book 4, Cardholder, Attendant, and Acquirer Interface Requirements,
Version 4.3, November 2011
[EMV A] EMV Contactless Specifications for Payment Systems - Book A -
Architecture and general requirements, Version 2.7, April 2018
[EMV B] EMV Contactless Specifications for Payment Systems - Book B - Entry
Point Specification, Version 2.7, April 2018
[EMV CDCVM] EMV White Paper, Platform Authentication for CDCVM, Version 1.1,
September 2017
[EMV PCMan] EMV Contactless Mobile Payment, Payment Card Management, White
Paper, Version 1.0, May 2017
[ISO 3166-1] Codes for the representation of names of countries and their
subdivisions - Part 1: Country codes
[ISO 4217] Codes for the representation of currencies and funds
[ISO 8583:1987] ISO 8583, Bank card originated messages - Interchange message
specifications - Content for financial transactions, 1987
[ISO 7810] ISO/IEC 7810, Identification cards - Physical characteristics
2.2 Definitions
In addition to those provided in Section 3 of [CPA], the definitions listed below are used in
this specification.
CVM-Limit An amount defined for the payment scheme, below which
contactless transactions without cardholder verification are allowed
Digital Card Set of data needed to emulate a payment card for HCE
Digital Card Handling The functionality which is to be supported by the HCE SDK for
Digital Card storage and management over the Mobile Payment
App interface and the HCE Server interface
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Abbreviations
15.03.2019 Page 10 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
CPACE-HCE EMV
processing
PPSE processing and EMV transaction processing functionality to
be supported by the HCE SDK for CPACE-HCE
HCE SDK Software1) integrated in the Mobile Payment App which implements
the functions needed for Digital Card transaction processing over
the contactless interface and for Digital Card storage and
management over the Mobile Payment App interface and the HCE
Server interface
HCE Server A server operated by or on behalf of the Digital Card issuer, to
which the HCE SDK connects for Digital Card provisioning and
management
Host Card Emulation
(HCE)
A method of card emulation on a mobile device with NFC
functionality, allowing any mobile app, i.e. any application on the
mobile device, to emulate a card and communicate (through the
NFC controller and platform of the mobile device) with an NFC
terminal.
Mobile Payment App A mobile app which has declared to the platform of the mobile
device that it implements an HCE service for payment, thus
emulating one or several payment cards
UI Module The module of the Mobile Payment App which offers and controls
the interface to the cardholder, i.e. cardholder information and
cardholder input
2.3 Abbreviations
In addition to those listed in Section 4.1 of [CPA], the abbreviations listed below are used in
this specification.
a Alphabetic
AAC Application Authentication Cryptogram
AC Application Cryptogram
1) In principle, SDK stands for "Software Development Kit" which is a set of software development tools that allows the
creation of applications for a certain software package. But it has become common to apply the term "HCE SDK" to an
actual piece of software which has been developed using the respective SDK.
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Abbreviations
15.03.2019 Page 11 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
ACK Acknowledgement (Cardholder Confirmation)
AES Advanced Encryption Standard
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
APDU Application Protocol Data Unit
ARC Authorisation Response Code
ARPC Authorisation Response Cryptogram
ARQC Authorisation Request Cryptogram
ATC Application Transaction Counter
b Binary
C Conditional
CCD Common Core Definitions
CCI Common Core Identifier
CDA Combined DDA/Application Cryptogram Generation
CDCVM Consumer Device Cardholder Verification Method
CDOL Card Risk Management Data Object List
CHC Cardholder Confirmation
CHV Cardholder Verification
CHV&C Cardholder Verification and Confirmation
CID Cryptogram Information Data
CLA Class Byte of the Command Message
CPA Common Payment Application
CSU Card Status Update
CVM Cardholder Verification Method
CVN Cryptogram Version Number
CVR Card Verification Results
DES Data Encryption Standard
DF Dedicated File, Directory
DGI Data Grouping Identifier
DKI Derivation Key Index
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Abbreviations
15.03.2019 Page 12 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
DOL Data Object List
EF Elementary File, Data File
EMV Europay, MasterCard, Visa
FCI File Control Information
GPO GET PROCESSING OPTIONS
HCE Host Card Emulation
IAD Issuer Application Data
IATD Issuer Authentication Data
ICC Integrated Circuit Card
IDD Issuer Discretionary Data
INS Instruction Byte of the Command Message
ISO International Organisation for Standardisation
Lc Length of the Command Data Field
Le Maximum Length of Data Expected in the Response Data Field
LP Length of the Proprietary Authentication Data (PAD) in the Issuer
Authentication Data, where LP may have the value 0 or 8
Lr Length of Response Data Field
M Mandatory
mPIN A CDCVM for which the cardholder enters a PIN on the consumer device
and a verification value derived from or based on this PIN is sent to the
issuer for verification in the IAD
n Numeric
NFC Near Field Communication, communication over the contactless interface
O Optional
P1 Parameter 1
P2 Parameter 2
PAD Proprietary Authentication Data
PDOL Processing Options Data Object List
PIN Personal Identification Number
POS Point Of Service
PPSE Proximity Payment System Environment
PTH Previous Transaction History
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Document Conventions
15.03.2019 Page 13 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
RFU Reserved for Future Use
SFI Short File Identifier
SW1 Status Byte One
SW2 Status Byte Two
TC Transaction Certificate
TLV Tag-Length-Value
TVR Terminal Verification Results
UI User Interface
var. variable
YYMMDD year, month, day
2.4 Document Conventions
This specification uses the data element format conventions and terminology defined in
Sections 4.3, 4.4 and 4.6 of [CPA]. This specification uses the notation defined in Section 4.2
of [CPA], with the additions and modifications described in Section 2.4.1 below. This
specification uses its own requirements notation as described in Section 2.4.2 below.
In this specification, the term "data dictionary" refers to Section 12 of this document.
2.4.1 Notation
In accordance with the EMV specification (e.g. [EMV 3], Section 5, Annexes A and B), the
following notation is used for data description in this specification:
An item of information is called a data element. A data element is the smallest piece
of information that may be identified by a name, a description of logical content, a
format, and a coding.
A data object consists of a tag, a length, and a value (TLV). The value field of a data
object may consist of either a single data element or one or more data objects. When
a data object encapsulates a single data element, it is called a primitive data object.
When a data object encapsulates one or more data objects, it is called a constructed
data object. The value field of a constructed data object is called a template.
In addition, this specification defines the following data items:
A structure is a collection of different data items, where each data item is either a
data element or a structure.
The data items that constitute a structure are referenced by the name of the structure
followed by the individual name of the respective data item, both separated by a dot.
For example, the data element Second Presentment Indicator which is part of the
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Document Conventions
15.03.2019 Page 14 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
structure Transaction History is referenced Transaction History.Second Presentment
Indicator.
A list is a collection of instances of the same data item representing a table or an
array. The actual values of the entries constituting the list may be different.
A numbered list is a list where a unique integer number (from a defined range) is
assigned to each entry. The numbers assigned to the entries are not necessarily
sequential.
The names of data items, i.e. of templates, data elements, lists and structures, defined in the
data dictionary or defined by EMV and used in this specification are written in italics to
distinguish them from the text, e.g.
Application Control
In addition to or as replacement of those described in Section 4.2 of [CPA], the notational
conventions described below are used in this specification.
'Name of Sub-Element' in
Data Item Name
Reference to a sub-element of a data item defined in the data
dictionary, e.g. 'Include Based on Transaction CVM' in No CVM
Counter Control = Include if Transaction CVM is No CVM
A <> B Value of A is different from the value of B.
A <= B Value of A is less than or equal to the value of B.
A >= B Value of A is greater than or equal to the value of B.
A XOR B The bit-wise exclusive-OR of the data blocks A and B. If one
data block is shorter than the other then it is first padded to the
left with sufficient binary zeros to make it the same length as
the other.
[x:y] Range of bytes of the referenced data element.
For example, Application Control[1:3] represents bytes 1, 2,
and 3 of the Application Control
[bx:y] Range of bits of the referenced data element.
For example, No CVM Counter[b4:1] represents bits b4, b3,
b2, and b1 of No CVM Counter
CPACE for Host Card Emulation References, Abbreviations and Document Conventions Version 1.0 Document Conventions
15.03.2019 Page 15 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
2.4.2 Requirement Notation
CPACE-HCE EMV processing and Digital Card Handling as well as their interfaces to Mobile
Payment App and HCE Server shall comply with the requirements specified in this document
that are labelled Req C.x.
Requirements are identified and numbered in bold. Heading and description of a requirement
are marked by a frame:
Req C.x Requirement heading
Requirement description
CPACE for Host Card Emulation Overview Version 1.0 Implementer-Options
15.03.2019 Page 16 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
3 Overview
3.1 Implementer-Options
3.1.1 CPA Implementer-Options
The implementer-options
Dynamic RSA,
VLP and
Application Security Counters
defined in Section 5.1 of [CPA] are not supported by CPACE-HCE EMV processing.
The implementer-options
Profile Selection Using Card Data,
Cryptogram Version '5'-only,
Cryptogram Version '6'-only,
Cryptogram Version '5' and '6'
defined in Section 5.1 of [CPA] (including the extensions according to Specification Bulletin
165) shall be supported for CPACE-HCE EMV processing according to the following
requirements.
Req C.1 Support of Profile Selection Using Card Data
CPACE-HCE EMV processing shall support the Profile Selection Using Card Data
implementer-option defined in [CPA] as described in Section 5.1.
Req C.2 Support of AES
The CPACE-HCE EMV processing shall support either the Cryptogram Version '5'-only
implementer-option or the Cryptogram Version '6'-only implementer-option as described in
Specification Bulletin 165.
3.1.2 Additional Implementer-Options
Additional implementer-options are defined by this specification. These additional
implementer-options are numbered IOn and listed in Table 1.
Implementer-Option Description
IO1: 2nd GENERATE AC command CPACE-HCE EMV processing that supports
this implementer-option supports the second
GENERATE AC command (including restart
of transaction processing).
CPACE for Host Card Emulation Overview Version 1.0 Command Support Requirements
15.03.2019 Page 17 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Implementer-Option Description
IO2: Support of additional AIDs CPACE-HCE EMV processing that supports
this implementer-option allows the issuer to
assign up to 16 AIDs to a Digital Card (see
Section 5.1).
IO3: Support of activation of several
Digital Cards
Digital Card Handling that supports this
implementer-option allows the Mobile
Payment App to activate more than one
Digital Card (see Section 5.2).
IO4: Support of Key Expiration Dates CPACE-HCE EMV processing that supports
this implementer-option supports expiration
dates for session keys (see Section 10).
Table 1: Additional Implementer-Options
3.2 Command Support Requirements
Req C.3 Supported commands
CPACE-HCE EMV processing shall support the commands listed in Table 2.
Command CLA INS
GENERATE APPLICATION CRYPTOGRAM (GENERATE AC) '80' 'AE'
GET PROCESSING OPTIONS '80' 'A8'
READ RECORD '00' 'B2'
SELECT '00' 'A4'
Table 2: Command Support Requirements
3.3 Performance Requirements
Req C.4 Performance requirements
CPACE-HCE EMV processing shall meet the performance requirements for cards according
to Section 10 of [EMV A]. Currently this implies a card tariff of 400ms for CPACE-HCE EMV
processing of a payment.
CPACE for Host Card Emulation General Command Information Version 1.0 State Machine
15.03.2019 Page 18 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
4 General Command Information
4.1 State Machine
CPACE-HCE EMV processing operates by receiving a command from an EMV terminal over
the contactless interface (via NFC Controller and Mobile Payment App), processing it, then
generating and sending a response to the terminal. After this, CPACE-HCE EMV processing
is ready to process a new command.
In the same way as [CPA] describes the CPA application (see Section 6.2 of [CPA]), this
specification describes CPACE-HCE EMV processing as a state machine. As a result of
CPACE-HCE EMV processing receiving and processing a command, the state may change
before CPACE-HCE EMV processing accepts the next command. The processing of
commands leads to transitions within the state machine.
4.1.1 States
Table 3 provides the states used by CPACE-HCE EMV processing.
State Description
IDLE No transaction in progress
SELECTED An AID and the Digital Card to which this AID is assigned are selected
INITIATED A transaction is initiated with the GET PROCESSING OPTIONS command
ONLINE A second GENERATE AC command is expected (only if IO1 is supported)
Table 3: CPACE-HCE EMV processing States
The states SELECTED, INITIATED and ONLINE are defined in [CPA].
State ONLINE is only used by CPACE-HCE EMV processing, if IO1 is supported.
State SCRIPT is defined in [CPA], but is not used by CPACE-HCE EMV processing, even if
IO1 is supported
State IDLE has been introduced for CPACE-HCE EMV processing. This state is not defined
in [CPA].
The states defined for CPACE-HCE EMV processing are described in more detail in the
remainder of this section.
IDLE
State IDLE indicates that no transaction is currently processed by CPACE-HCE EMV
processing. In this state, only the SELECT command is allowed, either to select the PPSE or
to select an AID.
SELECTED
Transaction processing starts in the state SELECTED. CPACE-HCE EMV processing goes
to the state SELECTED upon successfully processing a SELECT command with which an
AID is selected. The AID which is selected becomes the AID Selected for the current
transaction, i.e. the transaction which is started with the SELECT command. The Digital Card
to which the AID Selected is assigned becomes the currently selected Digital Card. CPACE-
CPACE for Host Card Emulation General Command Information Version 1.0 State Machine
15.03.2019 Page 19 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
HCE EMV processing uses the data of the currently selected Digital Card to process the
current transaction.
INITIATED
CPACE-HCE EMV processing goes to state INITIATED after successful processing of the
GET PROCESSING OPTIONS command. In this state, a new transaction is initiated.
Processing of the READ RECORD commands does not cause CPACE-HCE EMV
processing to transition to a new state. Successful processing of the first GENERATE AC
command causes CPACE-HCE EMV processing to transition to either the IDLE state or, if
IO1 is supported and the GENERATE AC command returns an ARQC type cryptogram, to
the ONLINE state.
ONLINE
CPACE-HCE EMV processing only goes to state ONLINE if IO1 is supported. If this is the
case, CPACE-HCE EMV processing transitions to this state after the processing of the first
GENERATE AC command if the response is an ARQC type cryptogram. In this state,
CPACE-HCE EMV processing is expecting a response from the issuer. CPACE-HCE EMV
processing accepts a second GENERATE AC command in this state. Successful processing
of the second GENERATE AC command causes CPACE-HCE EMV processing to transition
to the IDLE state.
4.1.2 Sequence of Commands and Transitions Between States
The following tables show the sequence of commands and transitions between the states of
CPACE-HCE EMV processing depending on whether IO1 is not supported (Table 4) or
supported (Table 5).
In these tables, the column headings describe the current state when a command is
received. The row headings indicate the command received. Each table entry gives the
resulting state when execution of the command is successful (SW1 SW2 = '9000') and when
execution of the command results in an error response (SW1 SW2 <> '9000').
"Not Allowed" indicates that the command is not permitted in the given state. CPACE-HCE
EMV processing shall discontinue processing the command, shall respond with an SW1
SW2 that indicates an error, should respond with SW1 SW2 = '6985' (Conditions of use not
satisfied), and shall remain in the current state.
In accordance with [CPA], if an error occurs in command processing for GENERATE AC or
GET PROCESSING OPTIONS, in a state in which the command is allowed, CPACE-HCE
EMV processing shall transition to the SELECTED state. For an error in processing any other
command CPACE-HCE EMV processing shall remain in the current state.
Note:
The SELECT command is allowed in all states. If execution of the SELECT command is
successful, then CPACE-HCE EMV processing transitions to state IDLE if the PPSE is
selected or to state SELECTED if an AID is selected. The AID which is selected, may be
CPACE for Host Card Emulation General Command Information Version 1.0 State Machine
15.03.2019 Page 20 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
the same as or different from the AID which was selected when the SELECT command
was received.
State
Command IDLE SELECTED INITIATED
GENERATE AC Not Allowed Not Allowed
IDLE
(success)
SELECTED
(error)
GET PROCESSING
OPTIONS Not Allowed
INITIATED
(success)
SELECTED
(error)
Not Allowed
READ RECORD Not Allowed
SELECTED
(success or
error)
INITIATED
(success or
error)
SELECT AID
SELECTED
(success)
IDLE
(error)
SELECTED
(success or
error)
SELECTED
(success)
INITIATED
(error)
SELECT PPSE
IDLE
(success or
error)
IDLE
(success)
SELECTED
(error)
IDLE
(success)
INITIATED
(error)
Table 4: Sequence of Commands and State Transitions for Commands if IO1 is not
supported
CPACE for Host Card Emulation General Command Information Version 1.0 State Machine
15.03.2019 Page 21 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
State
Command IDLE SELECTED INITIATED ONLINE
GENERATE AC Not Allowed
Not Allowed
if restart not
allowed
IDLE
(after restart
and success)
SELECTED
(after restart
and error)
IDLE
(success and
AAC)
ONLINE
(success and
ARQC)
SELECTED
(error)
IDLE
(success)
SELECTED
(error)
GET PROCESSING
OPTIONS Not Allowed
INITIATED
(success)
SELECTED
(error)
Not Allowed Not Allowed
READ RECORD Not Allowed
SELECTED
(success or
error)
INITIATED
(success or
error)
ONLINE
(success or
error)
SELECT AID
SELECTED
(success)
IDLE
(error)
SELECTED
(success or
error)
SELECTED
(success)
INITIATED
(error)
SELECTED
(success)
ONLINE
(error)
SELECT PPSE
IDLE
(success or
error)
IDLE
(success)
SELECTED
(error)
IDLE
(success)
INITIATED
(error)
IDLE
(success)
ONLINE
(error)
Table 5: Sequence of Commands and State Transitions for Commands if IO1 is
supported
A GENERATE AC command which is received when CPACE-HCE EMV processing is in the
state INITIATED is the first GENERATE AC command.
If IO1 is not supported, then only the first GENERATE AC command is supported by
CPACE-HCE EMV processing. In this case, a GENERATE AC command which is received
in a state different from INITIATED shall be rejected with SW1 SW2 = '6985.
If IO1 is supported, then a second GENERATE AC command is supported by CPACE-HCE
EMV processing. In this case, the following Req C.5 applies.
Req C.5 Check first or second GENERATE AC command - only applicable if
IO1 is supported
If a GENERATE AC command (i.e. CLA = '80' and INS = 'AE') is received, the decision
whether it is a first or second GENERATE AC command shall be taken as described below.
If CPACE-HCE EMV processing is in the state IDLE, the GENERATE AC command shall be
rejected with SW1 SW2 = '6985' without changing the state.
CPACE for Host Card Emulation General Command Information Version 1.0 Command Validation
15.03.2019 Page 22 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If CPACE-HCE EMV processing is in the state SELECTED, the GENERATE AC command
shall be:
accepted as second GENERATE AC command if a restart is allowed,
rejected with SW1 SW2 = '6985' without changing the state if a restart is not allowed.
A restart is allowed if and only if both of the following are true:
Transaction History.Restart Indicator = '01' (Restart allowed)
and Transaction History.AID Selected = AID Selected.
If CPACE-HCE EMV processing is in the state INITIATED, the GENERATE AC command
shall be accepted as first GENERATE AC command.
If CPACE-HCE EMV processing is in the state ONLINE, the GENERATE AC command shall
be accepted as second GENERATE AC command.
4.2 Command Validation
When a command APDU is received by CPACE-HCE EMV processing then it is checked
whether this APDU presents a correctly coded command.
Req C.6 Rejection of incorrect command APDUs
If CPACE-HCE EMV processing receives a command APDU which is not coded correctly
according to Section 11.1.1 of [EMV 1], CPACE-HCE EMV processing shall reject the
command APDU, shall respond with an SW1 SW2 that indicates an error, and should
respond with SW1 SW2 = '6700' (Wrong Length).
This includes rejection of command APDUs where the value of Lc is different from the actual
length of data.
CPACE-HCE EMV processing shall remain in the current state.
When a correctly coded command is received by CPACE-HCE EMV processing then it is
checked whether this command is known according to Section 3.2.
Req C.7 Command validation
If CPACE-HCE EMV processing receives an unknown command it shall discontinue
processing the command and shall respond with an SW1 SW2 indicating an error.
If the CLA is unknown, CPACE-HCE EMV processing should respond with SW1
SW2 = '6E00' (CLA not supported).
If the CLA is known, but the INS is unknown for the CLA, CPACE-HCE EMV
processing should respond with SW1 SW2 = '6D00' (Wrong INS).
If both the CLA and INS are unknown, CPACE-HCE EMV processing should
respond with SW1 SW2 = either '6E00' or '6D00'.
CPACE for Host Card Emulation General Command Information Version 1.0 Command Validation
15.03.2019 Page 23 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
In any case, CPACE-HCE EMV processing shall remain in the current state.
Note:
Like [CPA], this specification only describes CLA which indicate logical channel 0. This
implies that only logical channel 0 is supported by CPACE-HCE EMV processing.
Req C.8 Validation of command case and Le
If a known command is received and any of the following is true:
the command message contains a command data field, but the command does not
expect command data,
or Le is present in the command message, but the command does not return data in
its response according to its definition in [CPA] or in the specification,
or Le is present in the command message but has another value than '00',
then CPACE-HCE EMV processing shall discontinue processing the command, shall
respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2 =
'6700' (Wrong Length).
If Le <> '00' is detected in command processing for GENERATE AC or GET PROCESSING
OPTIONS, in a state in which the command is allowed, CPACE-HCE EMV processing shall
transition to the SELECTED state.
If a wrong command case or Le <> '00' is detected in processing any other command,
CPACE-HCE EMV processing shall remain in the current state.
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 Identifying and Selecting the Application
15.03.2019 Page 24 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
5 PPSE and Application Selection
5.1 Identifying and Selecting the Application
For a contactless terminal and a physical card, Application Selection is the function to select
which of the applications that are supported by both, card and terminal, will be used to
conduct the transaction. According to Section 3.3 of [EMV B], this function is performed in
two steps:
Selection of the PPSE to build the candidate list with the AIDs of the applications that
are supported by card and terminal
Final selection of one of the AIDs and thus one of the applications in the candidate
list.
To implement this terminal process for Digital Cards, AIDs are assigned to the Digital Cards
which are supported by the HCE SDK, and CPACE-HCE EMV processing supports selection
of these AIDs, i.e. processing of the SELECT command where the command data field
contains one of the AIDs. When an AID is selected in this way, the Digital Card to which the
AID is assigned is implicitly selected, and CPACE-HCE EMV processing uses the data which
constitutes this Digital Card for subsequent EMV transaction processing.
According to this specification, issuers may assign more than one AID to a Digital Card.
Req C.9 Support of several AIDs
IO2 supported:
Issuers shall have the option to assign up to 16 AIDs to a Digital Card.
IO2 not supported:
Issuers shall have the option to assign up to 2 AIDs to a Digital Card.
According to this specification, the Profile Selection Using Card Data implementer-option
defined in [CPA] shall be supported by associating a GPO Parameters Reference with each
AID that is assigned to a Digital Card. In this way it is indicated to CPACE-HCE EMV
processing which GPO Parameters x shall be used when the respective AID is selected.
Req C.10 Support of AID Table
CPACE-HCE EMV processing shall support an AID Table as described in Section 12.2 for
each Digital Card. The AID Table contains an entry (AID Entry) per AID assigned to the
Digital Card. An AID Entry associates the respective AID with a GPO Parameters
Reference. In addition, the AID Entry associates the respective AID with its individual FCI
Proprietary Template and PPSE Directory Entry.
A maximum length of 255 bytes shall be supported per AID Entry.
The FCI Proprietary Template which is associated with an AID through an AID Entry is used
to build the response message for the SELECT command with which the AID is selected
(see Section 5.3.3.2).
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 Activation and Prioritisation of Digital Cards
15.03.2019 Page 25 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
CPACE-HCE EMV processing also supports selection of the PPSE (referred to as PPSE
selection), i.e. processing of the SELECT command where the command data field contains
the name of the PPSE. When the PPSE is selected, CPACE-HCE EMV processing lists the
AID(s) which can be selected by the terminal in the response message for the SELECT
command. The PPSE Directory Entry/Entries which is/are associated with this/these AID(s)
through their respective AID Entry is/are used to build the response message for the
SELECT command with which the PPSE is selected (see Section 5.3.3.1).
Req C.11 Supported FCI length
CPACE-HCE EMV processing shall be capable of responding to a SELECT command for
the PPSE and for an AID with an FCI up to 240 bytes in length.
5.2 Activation and Prioritisation of Digital Cards
For PPSE selection CPACE-HCE EMV processing has to decide which AID(s) shall be listed
in the response message for the SELECT command.
As described in [EMV PCMan], according to this specification, this decision is based on the
information which of the Digital Cards supported by the HCE SDK is(are) activated (and
which priority order is assigned to the activated Digital Cards).
If IO3 is not supported, only one Digital Card can be activated. If IO3 is supported, several
Digital Cards can be activated and have to be prioritised.
Activation and, if IO3 is supported, prioritisation of Digital Cards, are to be set by the Mobile
Payment App. Methods to activate and prioritise Digital Cards normally involve cardholder
interactions but are out of scope for this specification.
According to this specification, the Mobile Payment App accesses Digital Card Handling over
the Mobile Payment App interface
to retrieve Digital Card information needed to activate and prioritise Digital Cards
and to provide the information which of the Digital Cards supported by the HCE SDK
is(are) activated and which priority order is assigned to the activated Digital Cards.
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 26 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.12 Activation and Prioritisation of Digital Cards
IO3 supported:
Digital Card Handling shall offer methods to the Mobile Payment App to indicate
which of the Digital Cards supported by the HCE SDK are activated and
which priority order is assigned to the activated Digital Card.
Digital Card Handling shall retain this information and make it available to the Mobile
Payment App and to CPACE-HCE EMV processing.
IO3 not supported:
Digital Card Handling shall offer methods to the Mobile Payment App to indicate
which of the Digital Cards supported by the HCE SDK is activated.
Digital Card Handling shall retain this information and make it available to the Mobile
Payment App and to CPACE-HCE EMV processing.
5.3 SELECT Command
5.3.1 Command Coding
According to Section 11.3.2 of [EMV 1], the SELECT command message is coded as
follows:
Code Value
CLA '00'
INS 'A4'
P1 '04': Select by name
P2 '00': First or only occurrence
Lc '05' - '10'
Data File name
Le '00'
Table 6: SELECT Command Message
5.3.2 Command Format Validation
Req C.13 Check P1 and P2 for SELECT command
If P1-P2 do not have the value '04 00', then CPACE-HCE EMV processing shall discontinue
processing the command, shall respond with an SW1 SW2 indicating an error, and should
respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-P2).
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 27 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.14 Check Activation of Digital Cards
If no Digital Card is activated, then CPACE-HCE EMV processing shall discontinue
processing the command, shall respond with an SW1 SW2 indicating an error, and should
respond with SW1 SW2 = '6A82' (File Not Found).
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 28 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
5.3.3 Processing
If the file name received in the data field of the SELECT command matches the name of the
PPSE ("2PAY.SYS.DDF01"), then processing shall continue as described in Section 5.3.3.1.
Else, processing shall continue as described in Section 5.3.3.2.
5.3.3.1 SELECT PPSE
Req C.15 Build Directory Entries for the PPSE
CPACE-HCE EMV processing shall build the FCI Issuer Discretionary Data for the PPSE
according to [EMV B] using the PPSE Directory Entries defined for the Digital Cards as
follows:
IO3 not supported:
CPACE-HCE EMV processing shall concatenate the PPSE Directory Entries contained
in the AID Entries of the AID Table assigned to this Digital Card in the sequence in which
the AID Entries are listed in the AID Table.
The PPSE Directory Entry contained in an AID Entry shall be appended at the end of the
concatenation of PPSE Directory Entries if the length of the concatenation of PPSE
Directory Entries including this PPSE Directory Entry is less than 226 bytes.
Else, the next the AID Entry, if any, shall be processed.
If any of the following errors is detected when the AID Table assigned to the activated
Digital Card is to be evaluated:
the AID Table is not present,
or the AID Table does not contain an AID Entry,
or an error is detected in the TLV coding of an AID Entry,
or a mandatory data object is missing in an AID Entry,
or the coding of a data object in an AID Entry is not correct or inconsistent,
or the same DF Name is contained in two AID Entries in the same AID Table,
then CPACE-HCE EMV processing shall discontinue processing the SELECT command,
shall respond with an SW1 SW2 that indicates an error, and should respond with
SW1 SW2 = '6985' (Conditions of use not satisfied).
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 29 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
IO3 supported:
For the Digital Card which is activated with the highest priority, CPACE-HCE EMV
processing shall concatenate the PPSE Directory Entries contained in the AID Entries of
the AID Table assigned to this Digital Card in the sequence in which the AID Entries are
listed in the AID Table.
The PPSE Directory Entry contained in an AID Entry shall be appended at the end of the
concatenation of PPSE Directory Entries if the length of the concatenation of PPSE
Directory Entries including this PPSE Directory Entry is less than 226 bytes.
Else, the next the AID Entry, if any, shall be processed.
If there is (at least) another activated Digital Card the process described below shall be
applied to each remaining activated Digital Card in the order of their assigned priority.
CPACE-HCE EMV processing shall process the AID Entries stored in the AID Table
assigned to the Digital Card in the sequence in which the AID Entries are listed in the
AID Table.
The PPSE Directory Entry contained in the AID Entry shall be appended at the end of
the concatenation of PPSE Directory Entries if neither of the following is true:
The AID contained in the AID Entry is also contained in the AID Table assigned to a
Digital Card which has already been processed.
The length of the concatenation of PPSE Directory Entries would be greater than or
equal to 226 bytes if the PPSE Directory Entry contained in the AID Entry was
appended.
Else, the next the AID Entry, if any, shall be processed.
If no activated Digital Card is left, building of the FCI Issuer Discretionary Data for the
PPSE is terminated.
If any of the following errors is detected when the AID Table assigned to any of the
activated Digital Card is to be evaluated:
the AID Table is not present,
or the AID Table does not contain an AID Entry,
or an error is detected in the TLV coding of an AID Entry,
or a mandatory data object is missing in an AID Entry,
or the coding of a data object in an AID Entry is not correct or inconsistent,
or the same DF Name is contained in two AID Entries in the same AID Table,
then CPACE-HCE EMV processing shall discontinue processing the SELECT command,
shall respond with an SW1 SW2 that indicates an error, and should respond with
SW1 SW2 = '6985' (Conditions of use not satisfied).
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 30 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.16 Build FCI for PPSE
The FCI to be returned in the response data field for the SELECT command for the PPSE
shall be built by encapsulating the concatenation of
the DF Name data object (tag '84') for the PPSE containing "2PAY.SYS.DDF01" ('32
50 41 59 2E 53 59 53 2E 44 44 46 30 31')
and an FCI Proprietary Template data object (tag 'A5', correct length)
in an FCI data object (tag '6F', correct length).
The FCI Proprietary Template shall only contain the FCI Issuer Discretionary Data built as
described in Req C.15 (tag 'BF0C', correct length).
Req C.17 Positive response to the SELECT PPSE command
CPACE-HCE EMV processing shall return a response message consisting of the FCI data
object built according to Req C.16 and SW1 SW2 = '9000'.
5.3.3.2 SELECT AID
CPACE-HCE EMV processing does not support selection with partial DF Name. Therefore,
for successful selection of an AID, the file name (AID) received in the data field of the
SELECT command must be identical to one of the AIDs assigned to any of the Digital Cards
assigned to the HCE SDK.
In addition, CPACE-HCE EMV processing only allows selection of one of the AIDs assigned
to the activated Digital Card(s).
Req C.18 AID supported check
CPACE-HCE EMV processing shall check whether the file name received in the data field of
the SELECT command is identical with an AID assigned to (one of) the activated Digital
Card(s) (see Req C.12). If several Digital Cards are activated, these Digital Cards shall be
checked in the order of their assigned priority.
If the file name received in the SELECT command data field does not match any of the AIDs
assigned to the activated Digital Cards, then CPACE-HCE EMV processing shall
discontinue processing the command, shall respond with an SW1 SW2 indicating an error,
and should respond with SW1 SW2 = '6A82' (File Not Found).
Else, CPACE-HCE EMV processing shall store the file name received in the data field of the
SELECT command in the data element AID Selected and shall identify the activated Digital
Card with the highest priority to which AID Selected is assigned as Digital Card to be
selected.
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 31 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.19 Retrieve FCI Proprietary Template and GPO Parameters Reference
The AID Table for the Digital Card to be selected shall be evaluated to retrieve the FCI
Proprietary Template to be returned in the response to the SELECT command and to
determine the GPO Parameters Reference to be used for GET PROCESSING OPTIONS
command processing.
If any of the following errors is detected when the AID Table is to be evaluated:
the AID Table is not present,
or the AID Table does not contain an AID Entry,
or an error is detected in the TLV coding of an AID Entry,
or a mandatory data object is missing in an AID Entry,
or the coding of a data object in an AID Entry is not correct or inconsistent,
then CPACE-HCE EMV processing shall discontinue processing the SELECT command,
shall respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2
= '6985' (Conditions of use not satisfied).
The AID Table shall be evaluated as follows, using the AID Selected stored according to
Req C.18:
CPACE-HCE EMV processing shall search for the first AID Entry in the AID Table for
which the AID Selected is equal to the DF Name (AID) in the AID Entry,
If such an AID Entry cannot be found in the AID Table, then CPACE-HCE EMV
processing shall discontinue processing the SELECT command, shall respond with
an SW1 SW2 that indicates an error, and should respond with SW1 SW2 = '6985'
(Conditions of use not satisfied).
If such an AID Entry is found, processing continues as follows with this AID Entry:
The GPO Parameters Reference is retrieved from the AID Entry. If the GPO
Parameters Reference is absent from the AID Entry, then the default value '01'
shall be used as GPO Parameters Reference.
The FCI Proprietary Template data object (including tag and length) is retrieved
from the AID Entry.
CPACE for Host Card Emulation PPSE and Application Selection Version 1.0 SELECT Command
15.03.2019 Page 32 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.20 Build FCI
The FCI to be returned in the response data field for the SELECT command shall be built by
encapsulating the concatenation of
a DF Name data object
and the FCI Proprietary Template data object retrieved according to Req C.19
in an FCI data object (tag '6F', correct length).
The DF Name in the value field of the DF Name data object shall be set to AID Selected.
Req C.21 Positive response to the SELECT command
The Digital Card to be selected is identified as the currently selected Digital Card.
The CPACE-HCE EMV processing shall return a response message consisting of the FCI
data object built according to Req C.20 and SW1 SW2 = '9000'.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 Introduction
15.03.2019 Page 33 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
6 Initiate Application Processing
6.1 Introduction
During Initiate Application Processing, the terminal indicates that EMV transaction
processing is beginning by sending the GET PROCESSING OPTIONS command. When
issuing this command, the terminal supplies any data elements requested in the Processing
Options Data Objects List (PDOL) which has optionally been provided in the response to the
SELECT command to the terminal during Application Selection.
During processing of the GET PROCESSING OPTIONS command, CPACE-HCE EMV
processing performs Profile Selection, which allows to differentiate functionality based on the
transaction environment or to abort the transaction.
After Profile Selection, CPACE-HCE EMV processing responds to the GET PROCESSING
OPTIONS command with the Application Interchange Profile (AIP) and the Application File
Locator (AFL) defined for the selected Profile. In this way, Profile Selection allows to select
between multiple AIPs and AFLs defined for a Digital Card when building the response to the
GET PROCESSING OPTIONS command.
For Profile Selection, the Check Types defined in [CPA] and additional Check Types defined
by this specification may be used.
The Check Types defined in [CPA] are used to compare the values of data elements
provided by the terminal with fixed values defined for the respective check. This allows, for
example, to check for specific values of the Transaction Type and to select a Profile which
does not require cardholder verification and cardholder consent, if the Transaction Type
indicates that the cardholder will be credited and not debited.
The additional Check Types defined by this specification allow to evaluate the status of
dynamic data of a Digital Card, i.e. the No CVM Accumulator, No CVM Counter, CHV Limit
and/or CHV Required for Next Transaction for selecting a Profile.
In detail, the following additional tests shall be supported for Profile Selection according to
this specification:
Test whether No CVM Accumulator + Transaction Amount is greater than No CVM
MaxAmount.
Test whether No CVM Counter + 1 is greater than No CVM MaxNumber.
Test whether Transaction Amount is greater than or equal to the CHV Limit.
Test whether CHV Required for Next Transaction is set.
Note:
For the tests including the Transaction Amount, the Transaction Amount has to be
present in and to be extracted from the GET PROCESSING OPTIONS command
data, i.e. the Transaction Amount has to be requested by the PDOL.
Currency conversion is currently not described for CPACE-HCE EMV processing
since it is assumed that CPACE-HCE EMV processing is used in single currency
schemes. In particular, processing of the additional Check Types using the
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 34 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Transaction Amount currently does not apply currency conversion, since it is
assumed that the transaction currency matches the currency of the No CVM
Accumulator and of the CHV Limit.
Profile Selection using the additional Check Types can be used, for example, to decide
whether Online PIN verification has to be requested from a kernel during transaction
processing and to return different AFLs accordingly: If a Digital Card allows transactions
without cardholder verification as long as the cumulate amount of these transactions does
not exceed a limit, the CVM List indicated in the AFL should contain a CV Rule with No CVM
Required as CVM. But if this limit would be exceeded by cumulating the transaction amount
of the current transaction, the CVM List indicated in the AFL should not allow No CVM
Required as CVM anymore but should require Online PIN verification.
6.2 GET PROCESSING OPTIONS Command
6.2.1 Command Coding
According to Section 6.5.8.2 of [EMV 3], the GET PROCESSING OPTIONS command
message is coded as follows:
Code Value
CLA '80'
INS 'A8'
P1 '00'
P2 '00'
Lc var.
Data PDOL Related Data
Le '00'
Table 7: GET PROCESSING OPTIONS Command Message
The command data, called PDOL Related Data, consists of a data object with tag '83' the
value field of which contains the values in the terminal of data elements whose tags and
lengths were listed in the PDOL, if a PDOL was sent to the terminal in the SELECT
response.
PDOL Related Data is interpreted by CPACE-HCE EMV processing as consisting of the data
described in Table 8.
Name Tag Length Value
PDOL Related Data '83' GPO Template Length GPO Input Data
Table 8: PDOL Related Data
Req C.22 Supported length for PDOL Related Data
At a minimum, CPACE-HCE EMV processing shall support PDOL Related Data length in
the range 2 to 128 bytes.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 35 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
6.2.2 Command Format Validation
The CPACE-HCE EMV processing shall support the Profile Selection Using Card Data (see
Req C.1) using the AID Table (see Req C.10). The GPO Parameters Reference has been
retrieved during PPSE and Application Selection (see Req C.19).
Req C.23 Retrieve GPO Parameters x from GPO Parameters Template
GPO Parameters x with x = GPO Parameters Reference determined according to Req C.19
shall be retrieved.
If either of the following is true:
the GPO Parameters x is missing
or the length of the GPO Parameters x is different from 2 bytes,
then the command shall be aborted with return code '69 85' (Conditions of use not satisfied).
Req C.24 Check P1 and P2 for GPO command
If P1-P2 have none of the values specified for the GPO command, then CPACE-HCE EMV
processing shall discontinue processing the command, shall respond with an SW1 SW2
indicating an error, and should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-
P2).
Req C.25 Minimum valid length for PDOL Related Data
If the value of Lc is less than 2, then CPACE-HCE EMV processing shall discontinue
processing the GPO command, shall respond with an SW1 SW2 that indicates an error, and
should respond with SW1 SW2 = '6700' (Wrong Length).
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 36 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.26 Check length and format of PDOL Related Data
If any of the following is true:
the PDOL Related Data do not consist of a correctly TLV coded data object with tag
'83',
or the value of the length field in the (correctly coded) data object with tag '83' is not
consistent with the length of the PDOL Related Data indicated in Lc,
or the value of the length field in the (correctly coded) data object with tag '83' does
not equal the value of the GPO Input Data Length parameter in the data element
GPO Parameters x used for the transaction,
then CPACE-HCE EMV processing shall discontinue processing the GPO command, shall
respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2 =
'6700' (Wrong Length).
6.2.3 Processing
Req C.27 Initialise Transaction Data and Internal Working Variables
CPACE-HCE EMV processing shall set Card Verification Results (CVR) to '00 00 00 00 00'
and CHV Required for This Transaction to '00'.
If IO1 is supported, then CPACE-HCE EMV processing shall
set the Restart Flag to '00',
set 'Issuer Authentication Not Performed' (byte 1, bit b2) in Card Verification Results
(CVR) to 'Issuer Authentication Data Not Received in Online Response' (byte 2, bit
b8) in Previous Transaction History (PTH),
set 'Issuer Authentication Failed' (byte 1, bit b1) in Card Verification Results (CVR) to
'Issuer Authentication Failed' (byte 1, bit b3) in Previous Transaction History (PTH).
Req C.28 Reset Restart Indicator
If IO1 is supported, then Transaction History.Restart Indicator shall be set to '00' (No
Restart) in non-volatile memory.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 37 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
6.2.4 Profile Selection Table Processing
Req C.29 Minimum size of the Profile Selection Table
At a minimum, CPACE-HCE EMV processing shall support up to 30 Profile Selection Entries
in the Profile Selection Table for each Digital Card supported by the HCE SDK where each
Profile Selection Entry may have, at a minimum, a length of up to 50 bytes.
Req C.30 Perform Profile Selection Table Processing
Profile Selection Table Processing shall be performed as described in the remainder of this
section.
If either of the following is true:
the Application Control is missing
or the length of the Application Control is different from 4 bytes,
then processing of the GET PROCESSING OPTIONS command shall be discontinued with
the response SW1 SW2 = '6985' (Conditions of use not satisfied).
If 'Activate Profile Selection Table' (byte 2, bit b4) in the Application Control has the value 0b,
the issuer has not requested to perform Profile Selection Table Processing. In this case the
transaction shall be processed using the default Profile ID '01'.
Else, the following steps shall be performed to determine the Profile to be used for the
transaction.
If either of the following is true:
the Profile Selection Table is missing in the Digital Card
or the Profile Selection Table does not contain at least one Profile Selection Entry,
then the process shall be terminated and the Profile ID used for the transaction shall be '7F'.
The Profile Selection Entries in the Profile Selection Table shall be processed in the order in
which the entries are stored in the Profile Selection Table. Processing starts with the first
entry.
If the Profile Selection Table does not contain at least one entry, the process shall be
terminated and the Profile ID used for the transaction shall be '7F'.
The Profile Selection Diversifier shall be retrieved from byte 2 of the GPO Parameters x. This
1-byte value shall be inserted at the beginning of the GPO Input Data. The resulting byte
sequence is called Extended GPO Input Data.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 38 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
A Profile Selection Entry shall be processed as follows:
1. If any of the following is true:
the length of the Profile Selection Entry is less than 7 bytes,
or the value of the Entry Length in byte 1 of a Profile Selection Entry is less than
6,
or the value of the Entry Length in byte 1 of a Profile Selection Entry is not
consistent with the length of the Profile Selection Entry,
then the process shall be terminated and the Profile ID used for the transaction shall
be '7F'.
If the value of the Entry Length in byte 1 of a Profile Selection Entry is less than the
length of the Profile Selection Entry, then the trailing bytes at the end of the entry
shall be ignored.
2. The Position P in Extended GPO Input Data is retrieved from byte 2 of the Profile
Selection Entry. The Length L of Extraction Block and/or Comparison Block is
retrieved from byte 3 of the Profile Selection Entry. The Number n of Comparison
Blocks is retrieved from byte 4 of the Profile Selection Entry.
If either of the following is true:
the value of the Entry Length in byte 1 of the Profile Selection Entry is not equal to
n*L+6,
or both of the following are true:
P is greater than 0 or n is greater than 0,
and L is equal to 0,
then the process shall be terminated and the Profile ID used for the transaction shall
be '7F'.
3. The Check Type is retrieved from byte n*L+5 of the Profile Selection Entry.
If the Check Type has a value different from '00', '01', '02', 'D3', '93', '40', '41' then the
process shall be terminated and the Profile ID used for the transaction shall be '7F'.
For Check Types '00', '01' and '02', processing shall continue with step 4.
For Check Type 'D3', processing shall continue with step 7.
For Check Type '93', processing shall continue with step 8.
For Check Type '40', processing shall continue with step 9.
For Check Type '41', processing shall continue with step 10.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 39 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
4. A value shall be extracted from the Extended GPO Input Data. The part to be
extracted is defined using the two parameters P and L.
If either of the following is true:
P is equal to 0,
or P and L would require extracting data beyond the length of the Extended GPO
Input Data,
then the process shall be terminated and the Profile ID used for the transaction shall
be '7F'.
5. The extracted Value shall be masked with the Bit Mask to force some bits to 0b. That
is, for each bit in the Bit Mask that is set to the value 0b, the corresponding bit in
extracted value shall be set to 0b.
If n is less than 2, i.e. if the Comparison Blocks do not contain a Bit Mask, the process
shall be terminated and the Profile ID used for the transaction shall be '7F'.
6. The test indicated by the Check Type shall be performed as follows:
Match (Check Type = '00')
It shall be tested whether the masked value extracted from the Extended GPO
Input Data is equal to any of the comparison value(s) in this Profile Selection
Entry.
If a match is found, then the Positive Action shall be performed.
If no match is found, then the Negative Action shall be performed.
Less Than (Check Type = '01')
It shall be tested whether the masked value extracted from the Extended GPO
Input Data is less than comparison value 1.
If the value of the masked extracted data is less than the value of
comparison value 1, then the Positive Action shall be performed.
If the value of the masked extracted data is greater than or equal to the
value of comparison value 1, then the Negative Action shall be
performed.
Greater Than (Check Type = '02')
It shall be tested whether the masked value extracted from the Extended GPO
Input Data is greater than comparison value 1.
If the value of the masked extracted data is greater than the value of
comparison value 1, then the Positive Action shall be performed.
If the value of the masked extracted data is less than or equal to the
value of comparison value 1, then the Negative Action shall be
performed.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 40 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
The Positive or Negative Action shall be evaluated as described in step 11.
7. Check Type 'D3' indicates that the No CVM Accumulator shall be used. In this case,
the following steps shall be performed:
a) If either of the following is true:
No CVM Accumulator is missing,
or No CVM Accumulator does not have the format n 12,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
b) If the Transaction Amount has not yet been extracted from the Extended GPO
Input Data, it shall be extracted now. The Transaction Amount shall be
extracted from the Extended GPO Input Data. The part to be extracted is
defined using the two parameters P and L.
If any of the following is true:
P is equal to 0,
or L is not equal to 6,
or P and L would require extracting data beyond the length of the
Extended GPO Input Data,
or the 6-byte value extracted from the Extended GPO Input Data does not
have the format n 12,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
No CVM Accumulator and Transaction Amount are used to compute the value
Temp No CVM Accumulator:
If No CVM Accumulator + Transaction Amount >= 1012:
Temp No CVM Accumulator := 1012 - 1.
Else:
Temp No CVM Accumulator := No CVM Accumulator + Transaction
Amount.
c) The No CVM MaxAmount shall be retrieved.
If either of the following is true:
No CVM MaxAmount is missing,
or the No CVM MaxAmount does not have the format n 12,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 41 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
d) The test shall be performed as follows:
It shall be tested whether Temp No CVM Accumulator is greater than the No
CVM MaxAmount.
If Temp No CVM Accumulator is greater than the No CVM MaxAmount, then
the Positive Action shall be performed.
If Temp No CVM Accumulator is less than or equal to the No CVM
MaxAmount, then the Negative Action shall be performed.
The Positive or Negative Action shall be evaluated as described in step 11.
8. Check Type '93' indicates that the No CVM Counter shall be used. In this case, the
following steps shall be performed:
a) If either of the following is true:
No CVM Counter is missing,
or the length of No CVM Counter is different from 1 byte,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
b) Temp No CVM Counter shall be computed:
If No CVM Counter has the value 'FF':
Temp No CVM Counter := 'FF'
Else:
Temp No CVM Counter := No CVM Counter + 1
c) The No CVM MaxNumber shall be retrieved.
If either of the following is true:
No CVM MaxNumber is missing,
or the length of No CVM MaxNumber is different from 1 byte,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
d) The test shall be performed as follows:
It shall be tested whether No CVM Counter is greater than the No CVM
MaxNumber.
If No CVM Counter is greater than the No CVM MaxNumber, then the Positive
Action shall be performed.
If No CVM Counter is less than or equal to the No CVM MaxNumber, then the
Negative Action shall be performed.
The Positive or Negative Action shall be evaluated as described in step 11.
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 42 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9. Check Type '40' indicates that the CHV Limit shall be used. In this case, the following
steps shall be performed:
a) If either of the following is true:
Issuer CHV Limit is missing,
or Issuer CHV Limit does not have the format n 12,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
b) The Issuer CHV&C Control shall be retrieved.
If either of the following is true:
Issuer CHV&C Control is missing,
or the length of Issuer CHV&C Control is different from 4 bytes,
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
c) If 'Cardholder CHV Limit' in Issuer CHV&C Control = APPLICABLE, then the
Cardholder CHV Limit shall be retrieved.
If either of the following is true:
'Cardholder CHV Limit' in Issuer CHV&C Control = NOT APPLICABLE,
or both of the following are true:
'Cardholder CHV Limit' in Issuer CHV&C Control = APPLICABLE,
and either of the following is true:
Cardholder CHV Limit is missing,
or Cardholder CHV Limit does not have the format n 12,
then CHV Limit := Issuer CHV Limit,
else CHV Limit := Minimum of Issuer CHV Limit and Cardholder CHV Limit.
d) If the Transaction Amount has not yet been extracted from the Extended GPO
Input Data, it shall be extracted now. The part to be extracted is defined using
the two parameters P and L.
If any of the following is true:
P is equal to 0,
or L is not equal to 6,
or P and L would require extracting data beyond the length of the
Extended GPO Input Data,
or the 6-byte value extracted from the Extended GPO Input Data does not
have the format n 12,
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 43 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
then the process shall be terminated and the Profile ID used for the
transaction shall be '7F'.
e) The test shall be performed as follows:
It shall be tested whether the Transaction Amount is greater than or equal to
the CHV Limit.
If the Transaction Amount is greater than or equal to the CHV Limit, then the
Positive Action shall be performed.
If the Transaction Amount is less than the Comparison Value, then the
Negative Action shall be performed.
The Positive or Negative Action shall be evaluated as described in step 11.
10. Check Type '41' indicates that CHV Required for Next Transaction shall be used. In
this case, the test shall be performed as follows:
If CHV Required for Next Transaction is present and has the value '01', then the
Positive Action shall be performed.
If CHV Required for Next Transaction is missing or has the value '00', then the
Negative Action shall be performed.
The Positive or Negative Action shall be evaluated as described in step 11.
11. The Positive or Negative Action shall be evaluated as follows:
Bit b8 of the (Positive or Negative) Action byte has the value 0:
If the value x of bits b7-b1 of the (Positive or Negative) Action byte is not equal to
'00', then x shall be the Profile ID used for the transaction.
Else, the Profile ID '7F' shall be used.
Bit b8 of the (Positive or Negative) Action byte has the value 1b:
If the value x of bits b7-b1 of the (Positive or Negative) Action byte is neither
equal to '00'
nor greater than RL - RC, where RC is the entry number of the currently
processed Profile Selection Entry and RL is the entry number of the last entry
in the Profile Selection Table
then the Profile Selection algorithm shall move down x Profile Selection Entries,
that is, to the Profile Selection Entry with the entry number RC + x.
Else, the process shall be terminated and the Profile ID used for the transaction
shall be '7F'.
If the Profile ID determined by the Profile Selection processing is '7F', then CPACE-HCE
EMV processing shall discontinue processing the GET PROCESSING OPTIONS command
and shall respond with SW1 SW2 = '6985' (Conditions of use not satisfied).
CPACE for Host Card Emulation Initiate Application Processing Version 1.0 GET PROCESSING OPTIONS Command
15.03.2019 Page 44 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Else, the Profile Control selected for the transaction shall be Profile Control x, where x is the
value of the Profile ID selected for the transaction.
6.2.5 Profile Behaviour
Req C.31 Retrieve Profile Control
If Profile Selection processing results in selection of a Profile ID in the range '01' to '7E' for
which an associated Profile Control x (where x is the value of the Profile ID selected for the
transaction) is present, then the Profile Control selected for the transaction shall be Profile
Control x.
If Profile Control x is not present in the Digital Card (where x is the value of the Profile ID
selected for the transaction), then CPACE-HCE EMV processing shall discontinue
processing the GPO command, and shall respond with SW1 SW2 = '6985' (Conditions of
use not satisfied).
Req C.32 Minimum number of AIP/AFL Entries supported
The Digital Card contains sets of AIP and AFL in AIP/AFL Entries that may be selected for
use within a Profile. At a minimum, CPACE-HCE EMV processing shall be able to support
up to six AIP/AFL Entries for each supported Digital Card.
Req C.33 Select AIP/AFL for response
If AIP/AFL Entry x is present, then the Digital Card shall use the AIP and AFL in AIP/AFL
Entry x to generate the GPO command response, where x is the value of the AIP/AFL ID in
the Profile Control.
If AIP/AFL Entry x is not present, then CPACE-HCE EMV processing shall discontinue
processing the GPO command, and shall respond with SW1 SW2 = '6985' (Conditions of
use not satisfied).
6.2.6 Response to GPO Command
Req C.34 Format GPO Response
Response to the GPO command shall be formatted as specified in [EMV 3], Part V,
Common Core Definitions, Section 6.5.8.4 for a CCD-compliant card.
CPACE for Host Card Emulation Read Application Data Version 1.0 Introduction
15.03.2019 Page 45 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
7 Read Application Data
7.1 Introduction
During Read Application Data, the terminal reads the card data necessary to process the
transaction. The terminal shall read the files and records indicated in the AFL using the
READ RECORD command identifying the file by its SFI. The AFL to be used is in the
response to the GET PROCESSING OPTIONS command. The SFIs used in the AFL should
be less than or equal to 10.
CPACE-HCE EMV processing is not required to support a file structure but shall support the
READ RECORD command i.e. shall be able to retrieve the data identified by an SFI and a
record number to return it in the response to the corresponding READ RECORD command.
For provisioning, the DGIs with tag '0XYY' where '0X' with X <= 'A' is the SFI and 'YY' is the
record number, are reserved to transport this data to the HCE Server (see Section 11.2).
7.2 READ RECORD Command
7.2.1 Command Coding
According to Section 6.5.11.2 of [EMV 3], the READ RECORD command message is coded
as follows:
Code Value
CLA '00'
INS 'B2'
P1 Record number
P2 Reference control parameter (see Table 10)
Lc Not present
Data Not present
Le '00'
Table 9: READ RECORD Command Message
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x - - - SFI
- - - - - 1 0 0 P1 is a record number
Table 10: READ RECORD Command Reference Control Parameter
7.2.2 Command Format Validation
Req C.35 Check P1 for READ RECORD command
If the P1 parameter has the value '00', CPACE-HCE EMV processing shall discontinue
processing the READ RECORD command, shall respond with an SW1 SW2 that indicates
an error, and should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-P2).
CPACE for Host Card Emulation Read Application Data Version 1.0 READ RECORD Command
15.03.2019 Page 46 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.36 Check P2 for READ RECORD command
If bits b3 to b1 of the P2 parameter do not have the value 100b, CPACE-HCE EMV
processing shall discontinue processing the READ RECORD command, shall respond with
an SW1 SW2 that indicates an error, and should respond with SW1 SW2 = '6A86' (Incorrect
Parameters, P1-P2).
7.2.3 Processing
A READ RECORD command is received for each record designated in the AFL sent to the
terminal during Initiate Application Processing.
Req C.37 SFI not found
If the SFI (bits b8 to b4) in the P2 parameter is not defined for the Digital Card, then
CPACE-HCE EMV processing shall discontinue processing the READ RECORD command,
shall respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2
= '6A82' (file not found).
Req C.38 Record not found
If the record number in the P1 parameter is not defined for the Digital Card, then CPACE-
HCE EMV processing shall discontinue processing the READ RECORD command and
respond with SW1 SW2 = '6A83' (record number does not exist).
CPACE-HCE EMV processing receives each READ RECORD command from the terminal
and returns the requested data to the terminal as described in Section 7.2.4.
7.2.4 Respond to READ RECORD Command
The command response returned by CPACE-HCE EMV processing includes a data field
which consists of the requested data.
For records in files with SFI in the range from 1 to 10, the data field of the response is
formatted as described in EMV Book 3, Section 6.5.11.4 (that is, with template tag '70', and
TLV coded).
Note:
The READ RECORD command returns the record as stored in the file. Therefore records
in files with SFI in the range from 1 to 10 have to be stored as TLV with record template
tag '70'.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 Communication with the Mobile Payment App
15.03.2019 Page 47 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8 First Card Action Analysis
First Card Action Analysis is performed by CPACE-HCE EMV processing if a GENERATE
AC command is received and accepted as first GENERATE AC command according to the
description in Section 4.1.2.
8.1 Communication with the Mobile Payment App
Req C.39 CDCVM cardholder verification supported by Mobile Payment App
For CDCVM cardholder verification (see Req C.62), CPACE-HCE EMV processing relies on
the Mobile Payment App to provide the data element Recent CDCVM Cardholder
Verification over the Mobile Payment App interface.
Recent CDCVM Cardholder Verification shall indicate whether CDCVM cardholder
verification for the transaction has occurred on the mobile device and, if this is the case,
date and time of the most recent CDCVM cardholder verification and
if the CDCVM cardholder verification was successful or if the result is unknown.
Therefore, if CDCVM cardholder verification is required according to the settings in
Application Control and Issuer CHV&C Control, then the Mobile Payment App must support
a method for CDCVM cardholder verification on the mobile device. Forcing a second
presentment for CDCVM cardholder verification may or may not be required by issuer or
cardholder settings in Issuer CHV&C Control or Cardholder CHV&C Control. Therefore, the
Mobile Payment App must support the cardholder interaction which has to be performed for
the CDCVM cardholder verification
during a transaction, after a first presentment of the mobile device to the contactless
terminal,
and before a transaction.
It is out of scope for this specification, which method(s) for CDCVM cardholder verification
is/are supported by the Mobile Payment App.
If the cardholder interaction for CDCVM cardholder verification is performed during a
transaction and if the cardholder does not perform the necessary steps or cancels the
verification then Recent CDCVM Cardholder Verification has to indicate that CDCVM
cardholder verification has not occurred.
If CDCVM cardholder verification has occurred with a CDCVM which requires verification by
the issuer, Cardholder Verification Data shall be made available to CPACE-HCE EMV
processing by the Mobile Payment App together with Recent CDCVM Cardholder
Verification.
The contents of Cardholder Verification Data is out of scope for CPACE-HCE EMV
processing.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 Communication with the Mobile Payment App
15.03.2019 Page 48 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.40 Cardholder confirmation supported by Mobile Payment App
For cardholder confirmation (see Req C.63), CPACE-HCE EMV processing relies on the
Mobile Payment App to provide the data element Recent Cardholder Confirmation over the
Mobile Payment App interface.
Recent Cardholder Confirmation shall indicate whether cardholder confirmation of the
transaction has occurred on the mobile device and, if this is the case, date and time of the
most recent cardholder confirmation.
Therefore, if cardholder confirmation is required according to the settings in Issuer CHV&C
Control, then the Mobile Payment App must support a method for cardholder confirmation
on the mobile device. Forcing a second presentment for cardholder confirmation may or
may not be required by issuer or cardholder settings in Issuer CHV&C Control or Cardholder
CHV&C Control. Therefore, the Mobile Payment App must support the cardholder
interaction which has to be performed for the cardholder confirmation
during a transaction, after a first presentment of the mobile device to the contactless
terminal,
and before a transaction.
It is out of scope for this specification, which method(s) for cardholder confirmation is/are
supported by the Mobile Payment App.
If cardholder confirmation is requested during a transaction and if the cardholder does not
confirm or cancels the confirmation then Recent Cardholder Confirmation has to indicate
that cardholder confirmation has not occurred.
If cardholder confirmation has occurred using a CDCVM and if this CDCVM requires
verification by the issuer, Cardholder Confirmation Data shall be made available to CPACE-
HCE EMV processing by the Mobile Payment App together with Recent Cardholder
Confirmation.
The contents of Cardholder Confirmation Data is out of scope for CPACE-HCE EMV
processing.
Req C.41 Notification of card action analysis completion
The Mobile Payment App interface shall allow CPACE-HCE EMV processing to notify the
Mobile Payment App upon completion of card action analysis.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 49 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2 First GENERATE AC Command
8.2.1 Command Coding
According to Section 6.5.5.2 of [EMV 3], the first GENERATE AC command message is
coded as follows:
Code Value
CLA '80'
INS 'AE'
P1 Reference Control Parameter (see Table 12)
P2 '00'
Lc var.
Data First GENERATE AC Command Data
Le '00'
Table 11: First GENERATE AC Command Message
Note:
First GENERATE AC Command Data is called Transaction-related data in [EMV 3].
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x - - - - - - Cryptogram Type
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - ARQC
1 1 - - - - - - RFU
- - x - - - - - RFU
- - - x - - - - CDA Requested
- - - 0 - - - - CDA Not Requested
- - - 1 - - - - CDA Requested
- - - - x x x x RFU
Table 12: First GENERATE AC Command Reference Control Parameter
Note:
CDA Requested and CDA Not Requested are respectively called CDA signature
requested and CDA signature not requested in [EMV 3].
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 50 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.42 Check Issuer Options Profile Control x
The Issuer Options Profile Control used in processing the transaction shall be Issuer
Options Profile Control x, where x is the Issuer Options Profile Control ID in the Profile
Control.
If any of the following is true:
the Issuer Options Profile Control ID in the Profile Control has the value '0',
or Issuer Options Profile Control x is missing,
or the length of Issuer Options Profile Control x is different from 10 bytes,
then processing of the first GENERATE AC command shall be discontinued and shall
respond with SW1 SW2 = '6985' (Conditions of use not satisfied).
Req C.43 Interpretation of first GENERATE AC command data
If and only if IO1 is supported, then interpretation of contents and length of the first
GENERATE AC command data field depends on the values of 'Restart Supported' (byte 8,
bit b4) and 'Restart only if Supported by Terminal' (byte 8, bit b3) in the Issuer Options
Profile Control.
If IO1 is not supported or, if IO1 is supported, any of the following is true:
'Restart Supported' in the Issuer Options Profile Control has the value 0b,
or 'Restart only if Supported by Terminal' in the Issuer Options Profile Control has
the value 0b,
or the length of the first GENERATE AC command data field is less than 35 bytes,
then the first GENERATE AC command data field shall be interpreted as consisting of the
data elements listed in Table 13, in the order shown.
If IO1 is supported and all of the following are true:
'Restart Supported' in the Issuer Options Profile Control has the value 1b,
and 'Restart only if Supported by Terminal' in the Issuer Options Profile Control has
the value 1b,
and the length of the first GENERATE AC command data field is greater than or
equal to 35 bytes,
then the first GENERATE AC command data field shall be interpreted as consisting of the
data elements listed in Table 14, in the order shown.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 51 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Element Length (in bytes)
Format
Bytes 1 - 6 Amount, Authorised 6 n 12
Bytes 7 - 12 Amount, Other 6 n 12
Bytes 13 - 14 Terminal Country Code 2 n 3
Bytes 15 - 19 Terminal Verification Results (TVR) 5 b
Bytes 20 - 21 Transaction Currency Code 2 n 3
Bytes 22 - 24 Transaction Date 3 YYMMDD
Byte 25 Transaction Type 1 n 2
Bytes 26 - 29 Unpredictable Number 4 b
Byte 30 Terminal Type 1 n 2
Bytes 31 - 33 Cardholder Verification Method (CVM) Results 3 b
Bytes 34 - (33+L) First GENERATE AC Extension Data of length L var. b
Table 13: First GENERATE AC Command Data without Terminal Risk Management
Data
Position Data Element Length
(in bytes)
Format
Bytes 1 - 6 Amount, Authorised 6 n 12
Bytes 7 - 12 Amount, Other 6 n 12
Bytes 13 - 14 Terminal Country Code 2 n 3
Bytes 15 - 19 Terminal Verification Results (TVR) 5 b
Bytes 20 - 21 Transaction Currency Code 2 n 3
Bytes 22 - 24 Transaction Date 3 YYMMDD
Byte 25 Transaction Type 1 n 2
Bytes 26 - 29 Unpredictable Number 4 b
Byte 30 Terminal Type 1 n 2
Bytes 31 - 33 Cardholder Verification Method (CVM) Results 3 b
Bytes 34 - 35 Terminal Risk Management Data (Bytes 1 - 2) 2 b
Bytes 36 - (35+L) First GENERATE AC Extension Data of length L var. b
Table 14: First GENERATE AC Command Data with Terminal Risk Management Data
8.2.2 Command Format Validation
Req C.44 Check P1 for GENERATE AC command
If 'Cryptogram Type' in the P1 parameter has the value 11b or 'CDA Requested' in the P1
parameter has the value 1b, CPACE-HCE EMV processing shall discontinue processing the
GENERATE AC command, shall respond with an SW1 SW2 that indicates an error, and
should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-P2).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 52 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.45 Check P2 for GENERATE AC command
If the P2 parameter is not set to the value '00', CPACE-HCE EMV processing shall
discontinue processing the GENERATE AC command, shall respond with an SW1 SW2 that
indicates an error, and should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-
P2).
Req C.46 Check first GENERATE AC command data length
If the value of Lc does not equal the value of First GENERATE AC Command Data Length
parameter in the Issuer Options Profile Control for the transaction, then the Digital Card
shall discontinue processing the command, shall respond with an SW1 SW2 that indicates
an error, and should respond with SW1 SW2 = '6700' (Wrong Length).
Req C.47 Check command data length at least meets the minimum length
allowed
If the value of Lc is less than 33 (the minimum length of CDOL related data), then CPACE-
HCE EMV processing shall discontinue processing the command, shall respond with an
SW1 SW2 that indicates an error, and should respond with SW1 SW2 = '6700' (Wrong
Length).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 53 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.48 Retrieve and initialise Transaction Data
The transaction data elements Amount, Authorised, Amount, Other, Terminal Country Code,
Terminal Verification Results (TVR), Transaction Currency Code, Transaction Date,
Transaction Type, Unpredictable Number, Terminal Type, Cardholder Verification Method
(CVM) Results shall be retrieved from the command data field.
The transaction data element CHV&CS shall be set to '00 00 00'.
If IO1 is supported, then the transaction data element Terminal Risk Management Data shall
be set as follows:
Terminal Risk Management Data := '00..00'
If all of the following are true:
'Restart Supported' in the Issuer Options Profile Control has the value 1b,
and 'Restart only if Supported by Terminal' in the Issuer Options Profile Control
has the value 1b,
and the length of the first GENERATE AC command data field is greater than or
equal to 35 bytes,
then Terminal Risk Management Data[1:2] := bytes 34 and 35 of first GENERATE
AC command data field.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 54 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.3 Processing
8.2.3.1 First GENERATE AC Checks
Req C.49 Check No CVM Accumulator Profile Control x, No CVM Accumulator,
No CVM MaxAmount and No CVM Accumulator Control
The No CVM Accumulator Profile Control used in processing the transaction shall be No
CVM Accumulator Profile Control x, where x is the No CVM Accumulator Profile Control ID
in the Profile Control.
If the No CVM Accumulator Profile Control ID in the Profile Control has the value 'F', then
the No CVM Accumulator is not active for the transaction.
If any of the following is true:
the No CVM Accumulator Profile Control ID in the Profile Control has the value '0',
or No CVM Accumulator Profile Control x is missing,
or the length of No CVM Accumulator Profile Control x is different from 3 bytes,
or No CVM Accumulator is missing,
or No CVM Accumulator does not have the format n 12,
or No CVM MaxAmount is missing,
or No CVM MaxAmount does not have the format n 12,
or No CVM Accumulator Control is missing,
or the length of No CVM Accumulator Control is different from 4 bytes,
then
No CVM Accumulator is not (no longer) active for the transaction,
and 'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set
to 1b.
In any case, processing shall continue with the No CVM Counter related checks (Req C.50).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 55 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.50 Check No CVM Counter Profile Control x, No CVM Counter, No CVM
MaxNumber and No CVM Counter Control
The No CVM Counter Profile Control used in processing the transaction shall be No CVM
Counter Profile Control x, where x is the No CVM Counter Profile Control ID in the Profile
Control.
If the No CVM Counter Profile Control ID in the Profile Control has the value 'F', then the No
CVM Counter is not active for the transaction.
If any of the following is true:
the No CVM Counter Profile Control ID in the Profile Control has the value '0',
or No CVM Counter Profile Control x is missing,
or the length of No CVM Counter Profile Control x is different from 2 bytes,
or No CVM Counter is missing,
or the length of No CVM Counter is not correct,
or No CVM MaxNumber is missing,
or the length of No CVM MaxAmount is not correct,
or No CVM Counter Control is missing,
or the length of No CVM Counter Control is different from 2 bytes,
then
No CVM Counter is not (no longer) active for the transaction,
and 'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set
to 1b.
In any case, processing shall continue with the Maximum Number of Days Without CHV
Check related check (Req C.51).
Req C.51 Check Number of Days Without CHV Limit, Last CHV Date in Days
and Transaction Date
If 'Activate Maximum Number of Days Without CHV Check' (byte 1, bit b5) in the Issuer
Options Profile Control has the value 0b, the Maximum Number of Days Without CHV
Check is not active for the transaction.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 56 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If any of the following is true:
Number of Days Without CHV Limit is missing,
or Number of Days Without CHV Limit does not have the format n 4,
or Last CHV Date in Days is missing,
or the length of Last CHV Date in Days is different from 2 bytes,
or the format of the Transaction Date is not valid,
or the Transaction Date converted to a date in days is (see Annex 1) is less than the
Last CHV Date in Days,
then
the Maximum Number of Days Without CHV Check is not (no longer) active for the
transaction
and 'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set
to 1b.
In any case, processing shall continue with the second presentment check (Req C.52).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 57 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.52 Check second presentment
If Transaction History.Second Presentment Indicator does not indicate "Second presentment
required" (this is a first presentment), then processing shall continue with the offline decline
requested check (Req C.53).
Else, if both of the following are true:
Transaction History.Second Presentment Indicator indicates "Second presentment
required",
and Transaction History.Time of First Presentment and Second Presentment
Timeout indicate that the time for a second presentment has elapsed,
then Transaction History.Second Presentment Indicator shall be set to indicate "No second
presentment required" (this is a first presentment) and processing shall continue with the
offline decline requested check (Req C.53).
Else, if both of the following are true:
Transaction History.Second Presentment Indicator indicates "Second presentment
required",
and any of the following is true:
Transaction History.Transaction Currency Code <> Transaction Currency Code,
or Transaction History.Amount, Authorised <> Amount, Authorised,
or Transaction History.Transaction Type <> Transaction Type,
then
'Context is conflicting' (byte 2, bit b4) in CHV&CS shall be set to 1b (Context is
conflicting),
and Transaction History.Second Presentment Indicator shall be set to indicate
"Second presentment failed",
and processing shall continue as described in Section 8.2.3.3 to generate a
response with an AAC type of Application Cryptogram.
Else (this is a second presentment),
'2nd Presentment Performed' (byte 5, bit b4) in the Card Verification Results (CVR)
shall be set to 1b,
and processing shall continue with the offline decline requested check (Req C.53).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 58 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.53 Offline decline requested
If an offline decline was requested with the first GENERATE AC command (P1 indicates
AAC) or if 'Offline Decline Required' in the Issuer Options Profile Control (byte 9, bit b4) has
the value 1b, then
Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required",
and processing shall continue as described in Section 8.2.3.3 to generate a
response with an AAC type of Application Cryptogram.
Else, processing shall continue with the terminal (erroneously) considers offline PIN Ok
check (Req C.54).
Req C.54 Terminal (erroneously) considers offline PIN Ok check
This check
provides the issuer notification of whether the terminal considers (in Cardholder
Verification Method (CVM) Results) that Offline PIN processing passed, indicating
that the terminal expects CDCVM cardholder verification to be performed,
and sets the CHV Required for This Transaction flag if this is the case.
If both of the following are true:
the CVM Performed in bits b6-b1 of byte 1 of the Cardholder Verification Method
(CVM) Results has the value "Plaintext PIN verification performed by ICC"
(000001b),
and the CVM Result in byte 3 of the Cardholder Verification Method (CVM) Results
indicates successful cardholder verification ('02'),
then
'Terminal (Erroneously) Considers Offline PIN OK' (byte 3, bit b3) in the Card
Verification Results (CVR) shall be set to 1b,
and CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the CHV Required for Next Transaction check
(Req C.55).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 59 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.55 CHV Required for Next Transaction check
This check
provides the issuer notification of whether the CHV Required for Next Transaction
flag indicates that cardholder verification has to be performed,
and sets the CHV Required for This Transaction flag if this is the case.
If CHV Required for Next Transaction is present and has the value '01', then
'CHV Required on Next Transaction' (byte 5, bit b8) in the Card Verification Results
(CVR) shall be set to 1b,
and CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the CHV Limit exceeded check (Req C.56).
Req C.56 CHV Limit exceeded check
This check
provides the issuer notification of whether the transaction amount, i.e. Amount,
Authorised, is greater than or equal to the CHV Limit,
and sets the CHV Required for This Transaction flag if this is the case.
The Issuer CHV&C Control shall be retrieved.
If Issuer CHV&C Control is missing, then the issuer has decided that this check shall be
skipped and processing shall continue with the No CVM Accumulator check (Req C.57).
If Issuer CHV&C Control is present but has a length which is different from 4 bytes, then
'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set to
1b,
and CHV Limit := '00..00'.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 60 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If Issuer CHV&C Control is present and has a length of 4 bytes, then CHV Limit shall be set
as follows:
If 'Issuer CHV Limit' in Issuer CHV&C Control = NOT APPLICABLE, then
CHV Limit := '99..99'.
If 'Issuer CHV Limit' in Issuer CHV&C Control = APPLICABLE, then the Issuer CHV
Limit shall be retrieved.
If either of the following is true:
Issuer CHV Limit is missing,
or Issuer CHV Limit does not have the format n 12,
then
'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set
to 1b,
and CHV Limit := '00..00'.
else, CHV Limit := Issuer CHV Limit.
If 'Cardholder CHV Limit' in Issuer CHV&C Control = NOT APPLICABLE, then
CHV Limit remains unchanged.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 61 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If 'Cardholder CHV Limit' in Issuer CHV&C Control = APPLICABLE, then the
Cardholder CHV Limit shall be retrieved.
If either of the following is true:
Cardholder CHV Limit is missing,
or Cardholder CHV Limit does not have the format n 12,
then CHV Limit remains unchanged.
else, CHV Limit := Minimum of CHV Limit and Cardholder CHV Limit.
If and only if both of the following are true:
CHV Limit < '99..99',
and any of the following is true:
CHV Limit = 0,
or Transaction Currency Code does not match CHV&C Currency Code (bytes 2-
3 of Issuer CHV&C Control),
or both of the following are true:
Transaction Currency Code matches CHV&C Currency Code (bytes 2-3 of
Issuer CHV&C Control),
and Amount, Authorised >= CHV Limit,
then
'CHV Limit Exceeded' (byte 5, bit b7) in the Card Verification Results (CVR) shall be
set to 1b,
and CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the No CVM Accumulator check (Req C.57).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 62 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.57 No CVM Accumulator check
This issuer-optional check
sets the CHV Required for This Transaction flag if the No CVM MaxAmount has
been exceeded by the No CVM Accumulator prior to the transaction or if the No CVM
MaxAmount would be exceeded by the No CVM Accumulator for this transaction,
and provides the issuer notification of whether the No CVM MaxAmount has been
exceeded by the No CVM Accumulator prior to the transaction.
If the No CVM Accumulator is not (no longer) active (see Req C.49) then processing shall
continue with the No CVM Counter check (Req C.58).
Else, if the No CVM Accumulator is active, then the following steps shall be performed:
If No CVM Accumulator > No CVM MaxAmount, then
'No CVM MaxAmount Exceeded' (byte 3, bit b6) in the Card Verification Results
(CVR) shall be set to 1b,
and CHV Required for This Transaction shall be set to '01'.
If the Transaction Currency Code matches the Accumulator Currency Code (bytes 1-
2 of No CVM Accumulator Control) then:
No CVM Accumulator and Transaction Amount are used to compute the value
Temp No CVM Accumulator:
If No CVM Accumulator + Transaction Amount >= 1012:
Temp No CVM Accumulator := 1012 - 1.
Else:
Temp No CVM Accumulator := No CVM Accumulator + Transaction Amount.
If Temp No CVM Accumulator > No CVM MaxAmount, then
CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the No CVM Counter check (Req C.58).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 63 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.58 No CVM Counter check
This issuer-optional check
sets the CHV Required for This Transaction flag if the No CVM MaxNumber has
been exceeded by the No CVM Counter prior to the transaction or if the No CVM
MaxNumber would be exceeded by the No CVM Counter for this transaction,
and provides the issuer notification of whether the No CVM MaxNumber has been
exceeded by the No CVM Counter prior to the transaction.
If the No CVM Counter is not (no longer) active (see Req C.50) then processing shall
continue with the Maximum number of days without CHV check (Req C.59).
Else, if the No CVM Counter is active then the following steps shall be performed:
If No CVM Counter > No CVM MaxNumber, then
'No CVM MaxNumber Exceeded' (byte 3, bit b8) in the Card Verification Results
(CVR) shall be set to 1b,
and CHV Required for This Transaction shall be set to '01'.
If either of the following is true:
'Include Only If Not Accumulated' (byte 1, bit b5) in the No CVM Counter Control
has the value 0b,
or either of the following is true:
the No CVM Accumulator is not (no longer) active according to Req C.49,
or the Transaction Currency Code does not match the Accumulator Currency
Code (bytes 1-2 of No CVM Accumulator Control),
then
No CVM Counter is used to compute the value Temp No CVM Counter:
If No CVM Counter = 'FF':
Temp No CVM Counter := 'FF'.
Else:
Temp No CVM Counter := No CVM Counter + 1.
If Temp No CVM Counter > No CVM MaxNumber, then
CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the Maximum Number of Days Without
CHV check (Req C.59).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 64 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.59 Maximum Number of Days Without CHV check
This issuer-optional check
provides the issuer notification of whether the Number of Days Without CHV Limit is
exceeded,
and sets the CHV Required for This Transaction flag if this is the case.
If the Maximum Number of Days Without CHV Check is not (no longer) active (see
Req C.51) then processing shall continue with the Online PIN requested check (Req C.60).
Else, if the Maximum Number of Days Without CHV Check is active then the following steps
shall be performed:
If the difference between Transaction Date converted to a date in days (see Annex 1)
and Last CHV Date in Days is greater than the Number of Days Without CHV Limit,
then
'Number of Days Without CHV Limit Exceeded' (byte 5, bit b6) in the Card
Verification Results (CVR) shall be set to 1b,
and CHV Required for This Transaction shall be set to '01'.
In any case, processing shall continue with the Online PIN requested check
(Req C.60).
Req C.60 Online PIN requested check
If both of the following are true:
the CVM Performed in bits b6-b1 of byte 1 of the Cardholder Verification Method
(CVM) Results has the value "Enciphered PIN verified online" (000010b),
and the CVM Result in byte 3 of the Cardholder Verification Method (CVM) Results
indicates result unknown ('00'),
then
Transaction CVM shall be set to "Online PIN" ('02'),
and Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required",
and processing shall continue as described in Section 8.2.3.2 with a request for
online authorisation,
else, processing shall continue with the CHV required check (Req C.61).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 65 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.61 CHV required check
If CHV Required for This Transaction = '01', then CDCVM cardholder verification is required
and processing shall continue with the CDCVM cardholder verification check (Req C.62),
else,
Transaction CVM shall be set to "No CVM" ('00') since cardholder verification is not
required,
and processing shall continue with the cardholder confirmation check (Req C.63).
Req C.62 CDCVM cardholder verification check
If either of the following is true:
'CDCVM Cardholder Verification Supported' (byte 1, bit b2) in the Application Control
has the value 0b (CDCVM Cardholder Verification not Supported),
or CDCVM Cardholder Verification Usage Limit = '00' (CDCVM cardholder
verification information provided by the Mobile Payment App may not be used),
then
Transaction CVM shall be set to "No CVM" ('00') since cardholder verification is not
possible,
and 'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set
to 1b,
and processing shall continue with the cardholder confirmation check (Req C.63).
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 66 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Else, i.e. if CDCVM cardholder verification is supported and CDCVM cardholder verification
information provided by the Mobile Payment App may be used, then processing of this
check continues as follows:
If any of the following is true:
Recent CDCVM Cardholder Verification and CDCVM Cardholder Verification
Timeout indicate that CDCVM cardholder verification has not occurred or is no longer
valid,
or date and time of the most recent CDCVM cardholder verification according to
Recent CDCVM Cardholder Verification are prior to date and time of the last CDCVM
cardholder verification according to Transaction History.CDCVM Cardholder
Verification History,
or both of the following are true:
date and time of the most recent CDCVM cardholder verification according to
Recent CDCVM Cardholder Verification are the same as date and time of the last
CDCVM cardholder verification according to Transaction History.CDCVM
Cardholder Verification History,
and the number of remaining transactions for this CDCVM cardholder verification
in Transaction History.CDCVM Cardholder Verification History is '00',
or all of the following are true:
Transaction History.Second Presentment Indicator does not indicate "Second
presentment required" (this is a first presentment),
and Issuer CHV&C Control is present,
and the length of Issuer CHV&C Control is 4 bytes,
and either of the following is true:
'Issuer Forced 2nd Presentment Setting' in Issuer CHV&C Control =
REQUIRED FOR CHV or REQUIRED FOR CHV & CHC
or all of the following are true:
'Cardholder Forced 2nd Presentment Setting' in Issuer CHV&C Control =
APPLICABLE,
and Cardholder CHV&C Control is present,
and the length of Cardholder CHV&C Control is 1 byte,
and 'Cardholder Forced 2nd Presentment Setting' in Cardholder CHV&C
Control = REQUIRED FOR CHV or REQUIRED FOR CHV & CHC
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 67 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
then
'CDCVM cardholder verification required' (byte 2, bit b1) in CHV&CS shall be set to
1b (CDCVM cardholder verification required),
and Transaction History.Second Presentment Indicator shall be set to indicate
"Second presentment required",
and processing shall continue as described in Section 8.2.3.3 to generate a
response with an AAC type of Application Cryptogram.
else
'CDCVM Cardholder Verification Performed' (byte 2, bit b4) in the Card Verification
Results (CVR) shall be set to 1b,
and Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required",
and Transaction History.CDCVM Cardholder Verification History shall be set as
follows:
if date and time of the most recent CDCVM cardholder verification according to
Recent CDCVM Cardholder Verification are later than date and time of the last
CDCVM cardholder verification according to the current value of Transaction
History.CDCVM Cardholder Verification History:
date and time of last CDCVM cardholder verification in Transaction
History.CDCVM Cardholder Verification History shall be set to date and time
of the most recent CDCVM cardholder verification according to Recent
CDCVM Cardholder Verification,
number of remaining transactions for this CDCVM cardholder verification in
Transaction History.CDCVM Cardholder Verification History shall be set to
CDCVM Cardholder Verification Usage Limit - 1,
if date and time of the most recent CDCVM cardholder verification according to
Recent CDCVM Cardholder Verification are the same as date and time of the last
CDCVM cardholder verification according to the current value of Transaction
History.CDCVM Cardholder Verification History:
date and time of last CDCVM cardholder verification in Transaction
History.CDCVM Cardholder Verification History shall remain unchanged,
number of remaining transactions for this CDCVM cardholder verification in
Transaction History.CDCVM Cardholder Verification History shall be
decremented by 1,
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 68 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
and the Transaction CVM shall be set as follows:
Transaction CVM shall be set to "CDCVM, successful" ('01') if Recent CDCVM
Cardholder Verification indicates that CDCVM cardholder verification was
successful,
Transaction CVM shall be set to "CDCVM, result unknown" ('11') if Recent
CDCVM Cardholder Verification indicates that the result of CDCVM cardholder
verification is unknown,
and processing shall continue as described in Section 8.2.3.2 with a request for
online authorisation.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 69 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.63 Cardholder confirmation check
The Issuer CHV&C Control has to be used for this check.
If Issuer CHV&C Control is missing, then the issuer has decided that this check shall be
skipped, Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required" and processing shall continue as described in Section 8.2.3.2
with a request for online authorisation.
If Issuer CHV&C Control is present, but has a length which is different from 4 bytes, then
'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set to
1b,
and CHC Limit := '00..00'.
If Issuer CHV&C Control is present and has a length of 4 bytes, then CHC Limit shall be set
as follows:
If 'Issuer CHC Limit' in Issuer CHV&C Control = APPLICABLE, then the Issuer CHC
Limit shall be retrieved.
If either of the following is true:
Issuer CHC Limit is missing,
or Issuer CHC Limit does not have the format n 12,
then CHC Limit := '00..00'.
Else, CHC Limit := Issuer CHC Limit
If 'Issuer CHC Limit' in Issuer CHV&C Control = NOT APPLICABLE, then
CHC Limit := '99..99'.
If 'Cardholder CHC Limit' in Issuer CHV&C Control = APPLICABLE, then the
Cardholder CHC Limit shall be retrieved.
If either of the following is true:
Cardholder CHC Limit is missing,
or Cardholder CHC Limit does not have the format n 12,
then CHC Limit remains unchanged.
Else, if and only if Cardholder CHC Limit < CHC Limit, then CHC Limit := Cardholder
CHC Limit
If 'Cardholder CHC Limit' in Issuer CHV&C Control = NOT APPLICABLE, then CHC
Limit remains unchanged.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 70 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If and only if both of the following are true:
CHC Limit < '99..99',
and any of the following is true:
CHC Limit = 0,
or Transaction Currency Code does not match CHV&C Currency Code (bytes 2-
3 of Issuer CHV&C Control),
or both of the following are true:
Transaction Currency Code matches CHV&C Currency Code (bytes 2-3 of
Issuer CHV&C Control),
and Amount, Authorised >= CHC Limit,
then cardholder confirmation is required.
If cardholder confirmation is not required, then Transaction History.Second Presentment
Indicator shall be set to indicate "No second presentment required" and processing shall
continue as described in Section 8.2.3.2 with a request for online authorisation.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 71 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If cardholder confirmation is required, then processing of this check continues as follows:
If Cardholder Confirmation Usage Limit = '00' (cardholder confirmation information provided
by the Mobile Payment App may not be used), then
'Check Failed' (byte 3, bit b2) in the Card Verification Results (CVR) shall be set to
1b,
and Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required",
and processing shall continue as described in Section 8.2.3.2 with a request for
online authorisation.
Else, i.e. if cardholder confirmation information provided by the Mobile Payment App may be
used, then processing of this check continues as follows:
If any of the following is true:
Recent Cardholder Confirmation and Cardholder Confirmation Timeout indicate that
cardholder confirmation has not occurred or is no longer valid,
or date and time of the most recent cardholder confirmation according to Recent
Cardholder Confirmation are prior to date and time of the last cardholder
confirmation according to Transaction History.Cardholder Confirmation History,
or both of the following are true:
date and time of the most recent cardholder confirmation according to Recent
Cardholder Confirmation are the same as date and time of the last cardholder
confirmation according to Transaction History.Cardholder Confirmation History,
and the number of remaining transactions for this cardholder confirmation in
Transaction History.Cardholder Confirmation History is '00',
or both of the following are true:
Transaction History.Second Presentment Indicator does not indicate "Second
presentment required" (this is a first presentment),
and either of the following is true:
'Issuer Forced 2nd Presentment Setting' in Issuer CHV&C Control =
REQUIRED FOR CHV & CHC
or all of the following are true:
'Cardholder Forced 2nd Presentment Setting' in Issuer CHV&C Control =
APPLICABLE,
and Cardholder CHV&C Control is present,
and the length of Cardholder CHV&C Control is 1 byte,
and 'Cardholder Forced 2nd Presentment Setting' in Cardholder CHV&C
Control = REQUIRED FOR CHV & CHC
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 72 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
then
'Cardholder confirmation (ACK) required' (byte 2, bit b2) in CHV&CS shall be set to
1b (Cardholder confirmation required)
and Transaction History.Second Presentment Indicator shall be set to indicate
"Second presentment required"
and processing shall continue as described in Section 8.2.3.3 to generate a
response with an AAC type of Application Cryptogram.
else
'Cardholder Confirmed' (byte 5, bit b6) in the Card Verification Results (CVR) shall
be set to 1b,
and Transaction History.Second Presentment Indicator shall be set to indicate "No
second presentment required",
and Transaction History.Cardholder Confirmation History shall be set as follows:
if date and time of the most recent cardholder confirmation according to Recent
Cardholder Confirmation are later than date and time of the last cardholder
confirmation according to the current value of Transaction History.Cardholder
Confirmation History:
date and time of last cardholder confirmation in Transaction
History.Cardholder Confirmation History shall be set to date and time of the
most recent cardholder confirmation according to Recent Cardholder
Confirmation,
number of remaining transactions for this cardholder confirmation in
Transaction History.Cardholder Confirmation History shall be set to
Cardholder Confirmation Usage Limit - 1,
if date and time of the most recent cardholder confirmation according to Recent
Cardholder Confirmation are the same as date and time of the last cardholder
confirmation according to the current value of Transaction History.Cardholder
Confirmation History:
date and time of last cardholder confirmation in Transaction
History.Cardholder Confirmation History shall remain unchanged,
number of remaining transactions for this cardholder confirmation in
Transaction History.Cardholder Confirmation History shall be decremented by
1,
and processing shall continue as described in Section 8.2.3.2 with a request for
online authorisation.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 73 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.3.2 Request for Online Authorisation of the Transaction
Req C.64 Sequence of processing
The transaction is to go online for authorisation, if an ARQC shall be sent in the response to
the first GENERATE AC command. If this is the case, all requirements contained in this
section apply.
After completion of the updates described in these requirements, processing shall continue
with the response to the first GENERATE AC command as described in Section 8.2.4.
Req C.65 Add Transaction Amount to No CVM Accumulator
If all of the following are true:
No CVM Accumulator is active for the transaction (see Req C.49),
and the transaction currency matches the accumulator currency,
and the Transaction CVM is "No CVM" ('00'),
then No CVM Accumulator shall be updated with Temp No CVM Accumulator which was
computed as described in Req C.57.
If the new value of No CVM Accumulator (i.e. Temp No CVM Accumulator) is greater than
the No CVM MaxAmount, No CVM MaxAmount Exceeded' (byte 3, bit b6) in the Card
Verification Results (CVR) shall be set to 1b.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 74 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.66 Increment No CVM Counter
If all of the following are true:
No CVM Counter is active for the transaction (see Req C.50),
and either of the following is true:
'Include Only If Not Accumulated' (byte 1, bit b5) in the No CVM Counter Control
has the value 0b,
or either of the following is true:
the No CVM Accumulator is not (no longer) active according to Req C.49,
or the Transaction Currency Code does not match the Accumulator Currency
Code (bytes 1-2 of No CVM Accumulator Control),
and the Transaction CVM is "No CVM" ('00'),
then No CVM Counter shall be updated with Temp No CVM Counter which was computed
as described in Req C.58.
If the new value of No CVM Counter (i.e. Temp No CVM Counter) is greater than the No
CVM MaxNumber, 'No CVM MaxNumber Exceeded' (byte 3, bit b8) in the Card Verification
Results (CVR) shall be set to 1b.
Req C.67 Reset No CVM Accumulator
If both of the following are true:
No CVM Accumulator is active for the transaction (see Req C.49),
and either of the following is true:
both of the following are true:
the Transaction CVM is "CDCVM, successful" ('01'),
and 'Reset No CVM Accumulator with Successful CHV' (byte 3, bit b7) in the
No CVM Accumulator Profile Control has the value 1b,
or both of the following are true:
either of the following is true:
the Transaction CVM is "Online PIN" ('02'),
or the Transaction CVM is "CDCVM, Result Unknown" ('11'),
and 'Reset No CVM Accumulator with CHV, Result Unknown' (byte 3, bit b6)
in the No CVM Accumulator Profile Control has the value 1b,
then No CVM Accumulator shall be updated with the value 0.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 75 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.68 Reset No CVM Counter
If both of the following are true:
No CVM Counter is active for the transaction (see Req C.50),
and either of the following is true:
both of the following are true:
the Transaction CVM is "CDCVM, successful" ('01'),
and 'Reset No CVM Counter with Successful CHV' (byte 3, bit b7) in the No
CVM Counter Profile Control has the value 1b,
or both of the following are true:
either of the following is true:
the Transaction CVM is "Online PIN" ('02'),
or the Transaction CVM is "CDCVM, Result Unknown" ('11'),
and 'Reset No CVM Counter with CHV, Result Unknown' (byte 2, bit b6) in
the No CVM Counter Profile Control has the value 1b,
then No CVM Counter shall be updated with the value 0.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 76 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.69 Update Last CHV Date in Days
If both of the following are true:
the Maximum Number of Days Without CHV Check is active for the transaction (see
Req C.51),
and either of the following is true:
both of the following are true:
the Transaction CVM is "CDCVM, successful" ('01'),
and 'Update Last CHV Date in Days with Successful CHV' (byte 9, bit b4) in
the Issuer Options Profile Control has the value 1b,
or both of the following are true:
either of the following is true:
the Transaction CVM is "Online PIN" ('02'),
or the Transaction CVM is "CDCVM, Result Unknown" ('11'),
and 'Update Last CHV Date in Days with CHV, Result Unknown' (byte 9, bit
b3) in the Issuer Options Profile Control has the value 1b,
then Last CHV Date in Days shall be updated with the Transaction Date converted to a date
in days (see Annex 1).
Req C.70 Reset CHV Required for Next Transaction
If either of the following is true:
the Transaction CVM is "CDCVM, successful" ('01'),
or both of the following are true:
either of the following is true:
the Transaction CVM is "CDCVM, Result Unknown" ('11')
or the Transaction CVM is "Online PIN" ('02'),
and 'Update CHV Required for Next Transaction with CHV, Result Unknown'
(byte 8, bit b1) in the Issuer Options Profile Control has the value 1b,
then CHV Required for Next Transaction shall be set or updated to '00'.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 77 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.71 Update CVR, CID for going online
Since the transaction shall be authorised online CPACE-HCE EMV processing shall
set 'Application Cryptogram Type Returned in First GENERATE AC' in the CVR to
the value 10b to indicate an ARQC.
set 'Application Cryptogram Type Returned in Second GENERATE AC' in the CVR
to the value 10b to indicate Second GENERATE AC Not Requested.
set the Cryptogram Information Data (CID) to the value '80' to indicate that an ARQC
is being returned and no advice is required.
8.2.3.3 Offline Decline of the Transaction
Req C.72 Update CVR, CID for offline decline
The transaction will be declined offline, if an AAC shall be sent in the response to the first
GENERATE AC command. If this is the case, CPACE-HCE EMV processing shall
set 'Application Cryptogram Type Returned in First GENERATE AC' in the CVR to
the value 00b to indicate an AAC.
set 'Application Cryptogram Type Returned in Second GENERATE AC' in the CVR
to the value 10b to indicate Second GENERATE AC Not Requested.
set the Cryptogram Information Data (CID) to the value '00' to indicate that an AAC is
requested and no advice is required,
continue processing with the response to the first GENERATE AC command as
described in Section 8.2.4.
8.2.4 Respond to GENERATE AC Command
Req C.73 Sequence of processing
The response to the first GENERATE AC command shall be prepared and returned
according to the requirements contained in the following sections:
Build Issuer Application Data (IAD),
Build Online Parameter,
Generate Application Cryptogram,
Store Transaction History,
Notify Mobile Payment App and
Return GENERATE AC Response.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 78 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.4.1 Build Issuer Application Data (IAD)
Req C.74 Build Issuer Application Data (IAD)
CPACE-HCE EMV processing shall build the Issuer Application Data (IAD) to be sent in the
GENERATE AC response, coded as specified in [EMV 3], Part V, Common Core
Definitions, Annex C.7, for a CCD-compliant application with a Format Code of 'A'. Table 15
describes the coding of the Issuer Application Data (IAD).
IAD Byte Description Value
1 Length '0F'
2 CCI Set to the value of the Profile CCI in the Issuer Options Profile Control for the transaction ('A5' or 'A6' for CCD-compliant Profiles)
3 DKI Set to the value of the Profile DKI in the Issuer Options Profile Control for the transaction
4-8 CVR Set by CPACE-HCE EMV processing
9-16 Counters See Req C.75
17 Length '0F'
18 Profile ID Set to the Profile ID used for the transaction
19-32 IDD See Req C.76
Table 15: Issuer Application Data (IAD)
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 79 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.75 Build Counters portion in the Issuer Application Data (IAD)
If the Default Issuer Application Data (IAD) are missing, then 32 bytes 'FF..FF' shall be
used.
The default value for the Counters portion (bytes 9-16 of the IAD) is personalised in bytes 9-
16 of the Default Issuer Application Data (IAD). Any portion of these bytes not populated as
described below shall contain the default value.
If both of the following are true:
No CVM Accumulator is active for the transaction (see Req C.49),
and 'Send No CVM Accumulator in IAD' in the No CVM Accumulator Profile
Control has the value 1b,
then bytes 1-6 of the Counters portion of the IAD shall be populated with:
the No CVM Accumulator Balance, if 'Send No CVM Accumulator Balance' in the
No CVM Accumulator Profile Control has the value 1b,
or the value of the No CVM Accumulator, if 'Send No CVM Accumulator Balance'
in the No CVM Accumulator Profile Control has the value 0b.
If both of the following are true:
No CVM Counter is active for the transaction (see Req C.50),
and 'Send No CVM Counter in IAD' in the No CVM Counter Profile Control has
the value 1b,
then the first of the not yet populated bytes (i.e. byte 7 or byte 1) of the Counters
portion of the IAD shall be populated with the value of the No CVM Counter.
In any case, the first of the not yet populated bytes (i.e. byte 8, byte 7 or byte 1) of
the Counters portion of the IAD shall be populated with the value of the Key Counter.
Req C.76 Build IDD in Issuer Application Data (IAD)
The default value for these bytes is personalised in bytes 19-32 of the Default Issuer
Application Data (IAD). Any portion of these bytes not populated as described below shall
contain the default value.
If all of the following are true:
Cardholder Verification Data has been provided by the Mobile Payment App,
and 'CDCVM Performed' in the Card Verification Results (CVR) has the value 1b,
and 'Include CHV or CHC Data in IAD' in the Issuer Options Profile Control has
the value 1b,
then the first byte(s) of the IDD shall be populated with the Cardholder Verification
Data.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 80 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If all of the following are true:
Cardholder Confirmation Data has been provided by the Mobile Payment App,
and 'CDCVM Performed' in the Card Verification Results (CVR) has the value 0b,
and 'Cardholder Confirmation Performed' in the Card Verification Results (CVR)
has the value 1b
and 'Include CHV or CHC Data in IAD' in the Issuer Options Profile Control has
the value 1b,
then the first byte(s) of the IDD shall be populated with the Cardholder Confirmation
Data.
If 'Include No CHV End Date in IAD' (byte 7, bit b8) in the Issuer Options Profile
Control has the value 1b, then the first three of the not yet populated bytes of the IDD
shall be populated with the No CHV End Date which shall be determined according
to Req C.77.
Note:
Since the maximum length of Issuer Options Profile Control and Cardholder
Confirmation Data is 9 bytes, at least 5 bytes will not be populated in the IDD
when this step is performed.
If both of the following are true:
'Include Static Issuer Data in IAD' in the Issuer Options Profile Control has the
value 1b
and the Static Issuer Data are present for the currently selected Digital Card,
then the first or all of the not yet populated bytes of the IDD shall be populated with
the Static Issuer Data or, if the Static Issuer Data consist of more bytes than remain
in the IDD, the leftmost byte(s) of the Static Issuer Data.
Note:
Since the maximum length of Issuer Options Profile Control and Cardholder
Confirmation Data is 9 bytes and the length of the No CHV End Date is 3 bytes,
at least 2 bytes will not be populated in the IDD when this step is performed.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 81 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If all of the following are true:
at least 1 byte remains in the IDD after including Cardholder Verification Data or
Cardholder Confirmation Data and/or No CHV End Date and/or Static Issuer
Data as described above,
and 'Include Dynamic Issuer Data in IAD' in the Issuer Options Profile Control
has the value 1b,
and the Dynamic Issuer Data are present for the currently selected Digital Card,
then the first or all of the not yet populated bytes of the IDD shall be populated with
the Dynamic Issuer Data or, if the Dynamic Issuer Data consist of more bytes than
remain in the IDD, the leftmost byte(s) of the Dynamic Issuer Data.
Req C.77 Determine No CHV End Date
If the Number of Days Without CHV Limit or the Last CHV Date in Days is missing in the
application or is not formatted correctly, the 3-byte value '00 01 01' shall be included in the
IDD as No CHV End Date.
Else,
No CHV End Date in days
:= Last CHV Date in Days + Number of Days Without CHV Limit
shall be computed.
If the resulting value is greater than 36525, the 3-byte value '991231' shall be included in the
IDD as No CHV End Date.
If the resulting value is less than 36526, the No CHV End Date in days shall be converted to
a date in the format YYMMDD as described in Annex E of [CPA]. The resulting 3-byte value
(in the format YYMMDD) shall be included in the IDD as No CHV End Date.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 82 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.4.2 Build Online Parameter
Req C.78 Build Online Parameter
If and only if all of the following are true:
The implementer-option IO1 is supported,
and an ARQC shall be returned in the first GENERATE AC response,
and 'Restart Supported' in the Issuer Options Profile Control has the value 1b,
and either of the following is true:
'Restart only if Supported by Terminal' in the Issuer Options Profile Control has
the value 0b,
or 'Restart Supported' in the Terminal Risk Management Data retrieved from the
first GENERATE AC command data has the value 1b,
and 'Indicate Restart to Terminal' in the Issuer Options Profile Control has the value
1b.
then the Online Parameter data object, i.e. the data object with tag '9F55', shall be built as
follows:
'9F55 01 80'.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 83 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.4.3 Generate Application Cryptogram
Req C.79 Generate Application Cryptogram
Depending on whether the Cryptogram Version '5'-only implementer-option or the
Cryptogram Version '6'-only implementer-option is supported, the Application Cryptogram
shall be generated as detailed in Section 8 of the CCD part of [EMV 2], for a CCD-compliant
application with Cryptogram Version '5' or '6' with the following modification regarding the
AC Session Key (KS) to be used:
If an AAC shall be sent in the response to the first GENERATE AC command
CPACE-HCE EMV processing shall generate a random Session Key and shall
compute the Application Cryptogram with this random session key.
In this case, an ATC with value '00 00' shall be used in the response data.
Else, (an ARQC shall be sent in the response to the first GENERATE AC command)
CPACE-HCE EMV processing shall proceed as follows:
The next session key shall be requested from the key database according to
Section 10.
If the Online Parameter data object shall not be generated according to Section
8.2.4.2 CPACE-HCE EMV processing shall indicate in the request for the session
key that the key shall be deleted. Else, CPACE-HCE EMV processing shall
indicate that the key may need to be requested once more.
If no session key is returned, then processing of the first GENERATE AC
command shall be discontinued and CPACE-HCE EMV processing shall respond
with an SW1 SW2 indicating an error, and should respond with SW1 SW2 =
'6985' (Conditions of use not satisfied).
Else, CPACE-HCE EMV processing shall compute the Application Cryptogram
with the session key that is returned.
In this case, the ATC returned together with the session key is used.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 84 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
8.2.4.4 Store Transaction History
Req C.80 Store Transaction History
Irrespective of the state CPACE-HCE EMV processing transitions to, Transaction History
shall be updated (persistently) for the Digital Card with the transaction data received in the
first GENERATE AC command data or generated during first GENERATE AC command
processing.
If and only if IO1 is supported, then Transaction History.Restart Indicator shall be updated
(persistently) as follows:
If the response to the first GENERATE AC is an ARQC and both of the following are true:
'Restart Supported' in the Issuer Options Profile Control has the value 1b,
and either of the following is true:
'Restart only if Supported by Terminal' in the Issuer Options Profile Control has
the value 0b,
or 'Restart Supported' in the Terminal Risk Management Data retrieved from the
first GENERATE AC command data has the value 1b,
then Transaction History.Restart Indicator shall be updated (persistently) with '01' (Restart
allowed).
Else, Transaction History.Restart Indicator shall remain '00' (No Restart).
8.2.4.5 Notify Mobile Payment App
Req C.81 Notification of card action analysis completion
The Mobile Payment App shall be notified that card action analysis processing is completed.
8.2.4.6 Return GENERATE AC Response
Req C.82 Data field in first GENERATE AC response message
The data field in the first GENERATE AC response message returned by the Digital Card
shall be coded as shown in Table 16.
The Cardholder Verification and Confirmation Status (CHV&CS) data object shall only be
included, if bytes 2-3 of Cardholder Verification and Confirmation Status (CHV&CS) <> '00
00', which implies that the Application Cryptogram is an AAC.
The Online Parameter data object shall only be included, if it was built according to Section
8.2.4.2, which implies that the Application Cryptogram is an ARQC.
CPACE for Host Card Emulation First Card Action Analysis Version 1.0 First GENERATE AC Command
15.03.2019 Page 85 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Tag Value Presence
'77' Response Message Template Format 2 M
'9F27' Cryptogram Information Data (CID) M
'9F36' Application Transaction Counter (ATC) M
'9F26' Application Cryptogram (AC) M
'9F10' Issuer Application Data (IAD) M
'DF4B' Cardholder Verification and Confirmation Status
(CHV&CS)
C
'9F55' Online Parameter C
Table 16: First GENERATE AC Response Message Data Field
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Communication with the Mobile Payment App
15.03.2019 Page 86 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9 Second Card Action Analysis - only if IO1 is supported
Second Card Action Analysis is performed by CPACE-HCE EMV processing if a GENERATE
AC command is received in the state SELECTED or in the state ONLINE and is accepted as
second GENERATE AC command according to Req C.5 in Section 4.1.2.
In particular, CPACE-HCE EMV processing only performs Second Card Action Analysis
when an online authorisation was requested during First Card Action Analysis.
9.1 Communication with the Mobile Payment App
Req C.83 Notification of card action analysis completion
The Mobile Payment App interface shall allow CPACE-HCE EMV processing to notify the
Mobile Payment App upon completion of card action analysis.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Data Update and Retrieval
15.03.2019 Page 87 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.2 Data Update and Retrieval
Req C.84 Data update and retrieval for second GENERATE AC processing
The data to be used for second GENERATE AC processing shall be updated and retrieved
as described below.
If the second GENERATE AC command is received in the state ONLINE, then the following
steps shall be performed:
The Restart Flag shall be set to '00' (No Restart).
Transaction History.Restart Indicator shall be updated (persistently) with '00' (No
Restart).
The transaction data elements needed for second GENERATE AC processing are
either still available in volatile memory or have to be retrieved from Transaction
History in non-volatile memory (see Section 8.2.4.4) and then stored transiently for
second GENERATE AC processing.
If the second GENERATE AC command is received in the state SELECTED, then the
following steps shall be performed:
The Restart Flag shall be set to '01' (Restart).
Transaction History.Restart Indicator shall be updated (persistently) with '00' (No
Restart).
The transaction data elements that were stored persistently in Transaction History
(see Section 8.2.4.4) shall be retrieved from non-volatile memory and shall be stored
transiently for second GENERATE AC processing.
If configuration data and dynamic data retrieved from non-volatile memory during first
GENERATE AC processing have been deleted from volatile memory, then the values of
these data elements shall be (re-)retrieved from non-volatile memory, when they are used
the first time during the processing of the second GENERATE AC command.
For the retrieval of Profile Control, Issuer Options Profile Control, No CVM Accumulator
related data, No CVM Counter related data and Maximum Number of Days Without CHV
Check related data, Req C.31, Req C.42, Req C.49, Req C.50 and Req C.51 apply.
According to Req C.84, it may be assumed for second Card Action Analysis that data has
been stored transiently during the processing of the first GENERATE AC command,
irrespective of whether they have intermediately been stored in and retrieved from non-
volatile memory.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 88 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.3 Second GENERATE AC Command
9.3.1 Command Coding
According to Section 6.5.5.2 of [EMV 3], the Second GENERATE AC command message is
coded as follows:
Code Value
CLA '80'
INS 'AE'
P1 Reference control parameter (see Table 18)
P2 '00'
Lc var.
Data Second GENERATE AC Command Data
Le '00'
Table 17: Second GENERATE AC Command Message
Note:
Second GENERATE AC Command Data is called Transaction-related data in [EMV 3].
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x - - - - - - Cryptogram Type
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - Not allowed for second GENERATE AC
1 1 - - - - - - RFU
- - x - - - - - RFU
- - - x - - - - CDA Requested
- - - 0 - - - - CDA Not Requested
- - - 1 - - - - CDA Requested
- - - - x x x x RFU
Table 18: Second GENERATE AC Command Reference Control Parameter
Note:
CDA Requested and CDA Not Requested are respectively called CDA signature
requested and CDA signature not requested in [EMV 3].
Req C.85 Interpretation of second GENERATE AC command data
Interpretation of contents and length of the second GENERATE AC command data field
depends on the values of 'Amounts Included in CDOL2' in the Application Control and
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control.
If 'Amounts Included in CDOL2' in the Application Control has the value 1b, and if
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control has
the value 0b, then the second GENERATE AC command data field shall be interpreted as
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 89 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
consisting of the data elements listed in Table 19, in the order shown. In particular, the IATD
has a length of 8 bytes.
If 'Amounts Included in CDOL2' in the Application Control has the value 0b, and if
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control has
the value 0b, then the second GENERATE AC command data field shall be interpreted as
consisting of the data elements listed in Table 20, in the order shown.
If 'Amounts Included in CDOL2' in the Application Control has the value 1b, and if
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control has
the value 1b, then the second GENERATE AC command data field shall be interpreted as
consisting of the data elements listed in Table 21, in the order shown.
If 'Amounts Included in CDOL2' in the Application Control has the value 0b, and if
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control has
the value 1b, then the second GENERATE AC command data field shall be interpreted as
consisting of the data elements listed in Table 22, in the order shown.
Position Data Element Length (in bytes)
Format
Bytes 1 - 8 Issuer Authentication Data (IATD) 8 b
Bytes 9 - 10 Authorisation Response Code (ARC) 2 an 2
Bytes 11 - 15 Terminal Verification Results (TVR) 5 b
Bytes 16 - 19 Unpredictable Number 4 b
Bytes 20 - 25 Amount, Authorised 6 n 12
Bytes 26 - 31 Amount, Other 6 n 12
Bytes 32 - (31+L) Second GENERATE AC Extension Data of length L var. b
Table 19: Second GENERATE AC Command Data Field: Amounts in CDOL2
Position Data Element Length (in bytes)
Format
Bytes 1 - 8 Issuer Authentication Data (IATD) 8 b
Bytes 9 - 10 Authorisation Response Code (ARC) 2 an 2
Bytes 11 - 15 Terminal Verification Results (TVR) 5 b
Bytes 16 - 19 Unpredictable Number 4 b
Bytes 20 - (19+L) Second GENERATE AC Extension Data of length L var. b
Table 20: Second GENERATE AC Command Data Field: No Amounts in CDOL2
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 90 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Element Length (in bytes)
Format
Bytes 1 - 16 Issuer Authentication Data (IATD), possibly padded 16 b
Bytes 17 - 18 Authorisation Response Code (ARC) 2 an 2
Bytes 19 - 23 Terminal Verification Results (TVR) 5 b
Bytes 24 - 27 Unpredictable Number 4 b
Bytes 28 - 33 Amount, Authorised 6 n 12
Bytes 34 - 39 Amount, Other 6 n 12
Bytes 40 - (39+L) Second GENERATE AC Extension Data of length L var. b
Table 21: Second GENERATE AC Command Data Field: Amounts and Proprietary
Authentication Data in CDOL2
Position Data Element Length (in bytes)
Format
Bytes 1 - 16 Issuer Authentication Data (IATD), possibly padded 16 b
Bytes 17 - 18 Authorisation Response Code (ARC) 2 an 2
Bytes 19 - 23 Terminal Verification Results (TVR) 5 b
Bytes 24 - 27 Unpredictable Number 4 b
Bytes 28 - (27+L) Second GENERATE AC Extension Data of length L var. b
Table 22: Second GENERATE AC Command Data Field: Proprietary Authentication
Data and No Amounts in CDOL2
Note:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile Control
will be set to the value 1b, if and only if the length of the IATD will be set to 16 in the
CDOL2 used in the respective Profile.
If this is the case the issuer may send Proprietary Authentication Data (PAD) in the IATD.
The presence/absence of PAD in the IATD is indicated by the value of a bit in the Card
Status Update (CSU), which is part of the standard first 8 bytes of the IATD.
If the issuer sends PAD in the IATD, the PAD have a fixed length of 8 bytes.
Irrespective of the presence/absence of PAD in the IATD sent by the issuer the terminal
is obliged to fill the IATD part of the second GENERATE AC command data field
according to CDOL2, that is, with a length of 16 bytes.
Consequently, the terminal will pad the actual IATD with '00'-bytes up to a length of 16
bytes, if the IATD sent by the issuer do not contain PAD.
The CPACE-HCE EMV processing will evaluate the CSU in order to determine the
presence/absence of PAD in the IATD sent by the issuer. In this way presence of
padding '00'-bytes added by the terminal will be detected.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 91 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.86 Support Extension Data Length
At a minimum, CPACE-HCE EMV processing shall support Second GENERATE AC
Extension Data length of up to 32 bytes.
Req C.87 Check P1 for GENERATE AC command
If 'Cryptogram Type' in the P1 parameter has the value 10b or the value 11b or 'CDA
Requested' in the P1 parameter has the value 1b, CPACE-HCE EMV processing shall
discontinue processing the GENERATE AC command, shall respond with an SW1 SW2 that
indicates an error, and should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-
P2).
Req C.88 Check P2 for GENERATE AC command
If the P2 parameter is not set to the value '00', CPACE-HCE EMV processing shall
discontinue processing the GENERATE AC command, shall respond with an SW1 SW2 that
indicates an error, and should respond with SW1 SW2 = '6A86' (Incorrect Parameters, P1-
P2).
Req C.89 Check second GENERATE AC command data length
If the value of Lc does not equal the value of Second GENERATE AC Command Data
Length parameter in the Issuer Options Profile Control, then CPACE-HCE EMV processing
shall discontinue processing the command, shall respond with an SW1 SW2 that indicates
an error, and should respond with SW1 SW2 = '6700' (Wrong Length).
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 92 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.90 Check value of Lc using Application Control and Issuer Options
Profile Control
If either of the following is true:
both of the following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile
Control has the value 0b,
and either of the following is true:
'Amounts Included in CDOL2' in the Application Control has the value 0b and
the value of Lc is less than 19,
or 'Amounts Included in CDOL2' in the Application Control has the value 1b
and the value of Lc is less than 31,
or both of the following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile
Control has the value 1b,
and either of the following is true:
'Amounts Included in CDOL2' in the Application Control has the value 0b and
the value of Lc is less than 27,
or 'Amounts Included in CDOL2' in the Application Control has the value 1b
and the value of Lc is less than 39,
then CPACE-HCE EMV processing shall discontinue processing the command, shall
respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2 =
'6700' (Wrong Length).
Req C.91 Validation of the second GENERATE AC command data field
If both of the following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile
Control has the value 0b,
and 'Proprietary Authentication Data (PAD) Included' in the Card Status Update
(CSU), that is bit b8 of byte 5 of the second GENERATE AC command data field,
has the value 1b,
then CPACE-HCE EMV processing shall discontinue processing the command, shall
respond with an SW1 SW2 that indicates an error, and should respond with SW1 SW2 =
'6985' (Conditions of use not satisfied).
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 93 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
The length LP of the Proprietary Authentication Data (PAD) shall be determined in the
following way:
If either of the following is true:
'Proprietary Authentication Data (PAD) Included' in the Card Status Update
(CSU) has the value 0b,
or bits b7-b6 of byte 4 of the Card Status Update (CSU), that is bits b7-b6 of
byte 8 of the second GENERATE AC command data field, have the value 00b,
then Proprietary Authentication Data (PAD) are not present in the Issuer
Authentication Data (IATD), that is, LP = 0.
Else, 8-byte Proprietary Authentication Data (PAD) are present in the Issuer
Authentication Data (IATD), that is, LP = 8.
If command format validation is passed successfully, the command data field of the second
GENERATE AC command (called second GENERATE AC command data) shall be
retrieved for further processing.
9.3.2 Configure Second Card Analysis
Req C.92 Use transaction data from second GENERATE AC command data
For processing the second GENERATE AC command CPACE-HCE EMV processing shall
use
Issuer Authentication Data (IATD), Authorisation Response Code, Terminal
Verification Results (TVR) and Unpredictable Number, received in the second
GENERATE AC command data,
the Amount, Authorised and Amount, Other received as follows:
If 'Amounts Included in CDOL2' in the Application Control has the value 0b, then
CPACE-HCE EMV processing shall use the Amount, Authorised and Amount,
Other received in the First GENERATE AC Command Data for processing the
second GENERATE AC command.
If 'Amounts Included in CDOL2' in the Application Control has the value 1b, then
CPACE-HCE EMV processing shall use the Amount, Authorised and Amount,
Other received in the second GENERATE AC command data for processing the
second GENERATE AC command.
The type of Authorisation Response Code in this command determines which path the
Second Card Action Analysis processing follows:
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 94 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.93 Processing if Authorisation Response Code <> "Y3" or "Z3"
If the Authorisation Response Code in the second GENERATE AC command has a value
other than "Y3" or "Z3" (indicating that the online authorisation completed and the terminal
received a response from the issuer during Online Processing), then processing shall
continue as described in Section 9.3.3.
Req C.94 Processing if Authorisation Response Code = "Y3" or "Z3"
If the Authorisation Response Code has a value of "Y3" or "Z3" (indicating that online
authorisation was requested but not completed during Online Processing, either because
the terminal did not support online processing or because a response from the issuer was
not received), then processing shall continue as described in Section 9.3.4.
9.3.3 Online Authorisation Completed
The following processing is performed if the transaction successfully went online (that is, the
Authorisation Response Code returned in the second Generate AC command data has a
value other than "Y3" or "Z3").
9.3.3.1 Issuer Authentication
Req C.95 Check Issuer Authentication Data (IATD)
If the Issuer Authentication Data (IATD) portion of the Second GENERATE AC Command
Data is not all zeroes, then CPACE-HCE EMV processing shall:
set 'Issuer Authentication Not Performed' in the Card Verification Results (CVR) to
the value 0b,
set 'Issuer Authentication Data Not Received in Online Response' in the Previous
Transaction History (PTH) to the value 0b,
perform Issuer Authentication processing according to Req C.96.
Else, CPACE-HCE EMV processing shall:
set 'Issuer Authentication Not Performed' in the Card Verification Results (CVR) to
the value 1b,
set 'Issuer Authentication Data Not Received in Online Response' in the Previous
Transaction History (PTH) to the value 1b,
decline the transaction as specified in Section 9.3.6 and Section 9.3.7.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 95 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.96 Perform Issuer Authentication
When Issuer Authentication Data (IATD) is returned in the second GENERATE AC
command data, Issuer Authentication shall be performed using the following steps:
1. Parse out the Card Status Update (CSU) from the received Issuer Authentication
Data (IATD).
2. The CPACE-HCE EMV processing requests from the key database the last used
key.
If no session key is delivered, then processing of the second GENERATE AC
command shall be discontinued and shall respond with SW1 SW2 = '6985'
(Conditions of use not satisfied).
According to this specification, Proprietary Authentication Data (PAD) are supported
and shall be used in the generation of the ARPC according to the description in
Section 8.2.2 of [EMV 2]. The length LP of the Proprietary Authentication Data (PAD)
to be included in ARPC generation has been determined according to Req C.91.
Note:
According to Req C.91, even if 'Proprietary Authentication Data (PAD) Included'
in the Card Status Update (CSU) has the value 1b, the length LP of the
Proprietary Authentication Data (PAD) to be included in ARPC generation may
be 0.
Using the Card Status Update (CSU) recovered in step 1 and the ARQC sent in the
first GENERATE AC response, generate an ARPC as specified in [EMV 2] for a
CCD-compliant application with Cryptogram Version '5', if the Cryptogram Version
'5'-only implementer-option is supported, or with Cryptogram Version '6' (which uses
AES), if the Cryptogram Version '6'-only implementer-option is supported.
3. Compare the ARPC generated in step 2 with the ARPC received in bytes 1 through 4
of the received Issuer Authentication Data.
4. Continue with the processing according to Req C.97.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 96 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.97 Branch according to Issuer Authentication result
If Issuer Authentication passes (that is, if the ARPCs match), then CPACE-HCE EMV
processing shall
set 'Issuer Authentication Failed' in the Card Verification Results (CVR) to the value
0b,
'Issuer Authentication Failed' in the Previous Transaction History (PTH) to the value
0b,
continue with CSU and PAD Processing as described in Section 9.3.3.2.
If Issuer Authentication fails (that is, if the ARPCs do not match), then CPACE-HCE EMV
processing shall:
set 'Issuer Authentication Failed' in the Card Verification Results (CVR) to the value
1b,
set 'Issuer Authentication Failed' in the Previous Transaction History (PTH) to the
value 1b,
decline the transaction as described in Section 9.3.6 and Section 9.3.7.
9.3.3.2 CSU and PAD Processing
After successful Issuer Authentication, CPACE-HCE EMV processing has verified that the
Card Status Update (CSU) received in Issuer Authentication Data (IATD) is valid. The Card
Status Update (CSU) for CPACE-HCE EMV processing shall be coded as specified in
Section 12.10.
Req C.98 Update of No CVM MaxAmount
The update of No CVM MaxAmount shall only be performed, if all of the following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile
Control has the value 1b,
and 'Proprietary Authentication Data (PAD) Included' in the CSU has the value 1b,
and 'New No CVM MaxAmount in PAD' (byte 4, bit b6) in the CSU has a the value
1b,
and bytes 3 to 8 of the PAD (see Table 61) retrieved from bytes 9 to 16 of the
second GENERATE AC command data have the format n 12.
In this case, No CVM MaxAmount shall be updated with bytes 3 to 8 of the PAD.
In any case, processing shall continue with the Update of No CVM MaxNumber (Req C.99).
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 97 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.99 Update of No CVM MaxNumber
The update of No CVM MaxNumber shall only be performed, if 'New No CVM MaxNumber
in byte 3' (byte 4, bit b5) in the CSU has the value 1b.
In this case, No CVM MaxNumber shall be set to byte 3 of the CSU.
In any case, processing shall continue with the Update of Number of Days Without CHV
Limit (Req C.100).
Req C.100 Update of Number of Days Without CHV Limit
The update of Number of Days Without CHV Limit shall only be performed, if all of the
following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile
Control has the value 1b,
and 'Proprietary Authentication Data (PAD) Included' in the CSU has the value 1b,
and 'New Number of Days Without CHV Limit in PAD' (byte 4, bit b7) in the CSU has
a the value 1b,
and bytes 1 to 2 of the PAD (see Table 61) retrieved from bytes 9 to 16 of the
second GENERATE AC command data have the format n 4.
In this case, Number of Days Without CHV Limit shall be updated with bytes 1 to 2 of the
PAD.
In any case, processing shall continue with the Update of No CVM Accumulator and No
CVM Counter (Req C.101).
Req C.101 Update of No CVM Accumulator and No CVM Counter
No CVM Accumulator and No CVM Counter shall be updated according to Req C.102 and
Req C.103 using the Update Bits, which shall be assigned to No CVM Accumulator and No
CVM Counter in the following way:
If 'Individual Update of No CVM Accumulator and No CVM Counter' (byte 4, bit b8) in
the CSU has the value 1b, then individual Update Bits shall be assigned to No CVM
Accumulator and No CVM Counter as shown in Table 23.
Else, 'Update No CVM Accumulator (and No CVM Counter)' (byte 2, bits b2-b1) in
the CSU shall be assigned to No CVM Accumulator and No CVM Counter as Update
Bits.
In any case, after updating No CVM Accumulator and No CVM Counter according to
Req C.102 and Req C.103, processing shall continue with the update of Last CHV Date in
Days (Req C.104).
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 98 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Update Bits Assigned to
'Update No CVM Accumulator (and No CVM Counter)' (byte 2,
bits b2-b1) in the CSU
No CVM Accumulator
'Update No CVM Counter' (byte 4, bits b4-b3) in the CSU No CVM Counter
Table 23: Individual Update Bits Assigned to No CVM Accumulator and No CVM
Counter
Req C.102 Update No CVM Accumulator
If any of the following is true:
Update Bits with the value 00b have been assigned to the No CVM Accumulator,
or the No CVM Accumulator is not (no longer) active (see Req C.49),
or 'Reset Accumulator with Online Response' (byte 1, bit b7) in the No CVM
Accumulator Profile Control has the value 0b,
then the No CVM Accumulator shall remain unchanged.
Else, No CVM Accumulator shall be updated with
the value 0 if the Update Bits 10b have been assigned to it,
the No CVM MaxAmount if the Update Bits 01b have been assigned to it.
Note:
If No CVM MaxAmount shall be updated according to Req C.98, No CVM
Accumulator shall be updated this new value of No CVM MaxAmount.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 99 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Req C.103 Update No CVM Counter
If any of the following is true:
Update Bits with the value 00b have been assigned to the No CVM Counter,
or the No CVM Counter is not (no longer) active (see Req C.50),
or 'Reset Counter with Online Response' (byte 1, bit b3) in the No CVM Counter
Profile Control has the value 0b,
then the No CVM Counter shall remain unchanged.
Else, the No CVM Counter shall be updated with
the value 0 if the Update Bits 10b have been assigned to it,
the No CVM MaxNumber if the Update Bits 01b have been assigned to it.
Note:
If No CVM MaxNumber shall be updated according to Req C.99, No CVM
Counter shall be updated this new value of No CVM MaxNumber.
Req C.104 Update Last CHV Date in Days
If all of the following are true:
the Maximum Number of Days Without CHV Check is active for the transaction (see
Req C.51),
and 'Reset Last CHV Date in Days with Online Response' (byte 1, bit b4) in the
Issuer Options Profile Control has the value 1b,
and 'Update Last CHV Date in Days' (byte 4, bit b2) in the CSU has the value 1b,
then Last CHV Date in Days shall be updated with the Transaction Date converted to a date
in days (see Annex 1).
In any case, processing shall continue with the decision to approve or decline the
transaction (Req C.105).
Req C.105 Use CSU to decide to approve or decline the transaction
If both of the following are true:
the terminal requested a TC type Application Cryptogram
and 'Issuer Approves Online Transaction' in the CSU has the value 1b.
then the transaction shall be approved as described in Section 9.3.5 and Section 9.3.7.
Else, the transaction shall be declined as described in Section 9.3.6 and Section 9.3.7.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 100 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.3.4 Online Authorisation Not Completed
Req C.106 Set bits when online processing not completed
When the second GENERATE AC command from the terminal contains an Authorisation
Response Code indicating that online processing was requested but not completed ("Y3" or
"Z3"), CPACE-HCE EMV processing shall:
Set 'Issuer Authentication Not Performed' in the Card Verification Results (CVR) to
the value 1b
The transaction shall be declined as described in Section 9.3.6 and Section 9.3.7
9.3.5 Application Approves Transaction (TC)
When the transaction is to be approved, a Transaction Certificate (TC) type Application
Cryptogram is returned in the response to the second GENERATE AC command.
Req C.107 Update CVR bits and CID when approve transaction
Prior to building the Issuer Application Data data element and generating the response
cryptogram, CPACE-HCE EMV processing shall set 'Application Cryptogram Type Returned
in Second GENERATE AC' in the CVR to the value 01b (TC).
Prior to responding to the GENERATE AC command, CPACE-HCE EMV processing sets
the Cryptogram Information Data (CID) to the value '40' (TC) to indicate to the terminal that
the Application Cryptogram in the GENERATE AC response is a TC.
9.3.6 Application Declines Transaction (AAC)
When the transaction is to be declined, an AAC type Application Cryptogram is returned in
the second GENERATE AC response.
Req C.108 Update CVR bits and CID when decline transaction
Prior to generating the response cryptogram, CPACE-HCE EMV processing shall set
'Application Cryptogram Type Returned in Second GENERATE AC' in the CVR to the value
00b (AAC).
Prior to responding to the GENERATE AC command, CPACE-HCE EMV processing sets
the Cryptogram Information Data (CID) to the value '00' (AAC) to indicate to the terminal that
the Application Cryptogram in the GENERATE AC response is an AAC.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 101 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.3.7 Respond to GENERATE AC Command
Req C.109 Sequence of processing
The response to the second GENERATE AC command shall be prepared and returned
according to the requirements contained in the following sections:
Build Issuer Application Data,
Generate Application Cryptogram,
Store Transaction History,
Notify Mobile Payment App and
Return GENERATE AC Response.
9.3.7.1 Build Issuer Application Data
Req C.110 Build IAD
The Issuer Application Data (IAD) shall be built as described in Section 8.2.4.1 using the
current values of the data elements that are relevant for building the Issuer Application Data
(IAD).
9.3.7.2 Generate Application Cryptogram
Req C.111 Generate Application Cryptogram
Depending on whether the Cryptogram Version '5'-only implementer-option or the
Cryptogram Version '6'-only implementer-option is supported, the Application Cryptogram
shall be generated as detailed in Section 8 of the CCD part of [EMV 2], for a CCD-compliant
application with Cryptogram Version '5 ' or '6' with the following modification regarding the
AC Session Key (KS) to be used:
If CPACE-HCE EMV processing has not yet received the last used key during ARPC
checking it shall request the last used key from the key database.
If no session key is returned, then processing of the second GENERATE AC
command shall be discontinued and CPACE-HCE EMV processing shall respond
with an SW1 SW2 indicating an error, and should respond with SW1 SW2 = '6985'
(Conditions of use not satisfied).
Else, CPACE-HCE EMV processing shall compute the Application Cryptogram with
the session key that is returned.
CPACE for Host Card Emulation Second Card Action Analysis - only if IO1 is supported Version 1.0 Second GENERATE AC Command
15.03.2019 Page 102 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
9.3.7.3 Store Transaction History
Req C.112 Store Transaction History
The CPACE-HCE EMV processing shall store Transaction History in non-volatile memory.
9.3.7.4 Notify Mobile Payment App
Req C.113 Notification of card action analysis completion
The Mobile Payment App shall be notified that card action analysis processing is completed.
9.3.7.5 Return GENERATE AC Response
Req C.114 Data field in second GENERATE AC response message
The data field in the second GENERATE AC response message returned by CPACE-HCE
EMV processing shall be coded as shown in Table 24.
Tag Value Presence
'77' Response Message Template Format 2 M
'9F27' Cryptogram Information Data (CID) M
'9F36' Application Transaction Counter (ATC) M
'9F26' Application Cryptogram (AC) M
'9F10' Issuer Application Data (IAD) M
Table 24: Second GENERATE AC Response Message Data Field
CPACE for Host Card Emulation Handling of symmetric keys Version 1.0 Second GENERATE AC Command
15.03.2019 Page 103 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
10 Handling of symmetric keys
Req C.115 Security of cryptographic keys
The HCE SDK shall support an internal and secured key database and shall ensure that it is
not feasible for an attacker to determine the values of secret cryptographic keys. The keys
are only provided to CPACE-HCE EMV processing.
Req C.116 Key Handling
For each Digital Card stored by the HCE SDK, the key data base shall store a set of session
keys. For each session key, the key data base shall also store which ATC was used to
derive the session key. The ATC which was used to derive a session key is considered
assigned to the respective session key.
In addition, if IO4 is supported, the key data base shall store an Expiration Date as assigned
to each session key stored in the key database.
Note:
If IO4 is supported, the same Expiration Date may be assigned to several session keys.
For example, the same Expiration Date may be assigned to all session keys replenished
at the same time for the same Digital Card.
In order to compute an Application Cryptogram within a transaction CPACE-HCE EMV
processing sends an internal request to the key database to get the next session key to be
used for the indicated Digital Card. Therefore the key database needs to implement for each
Digital Card an order of the stored session keys based on the assigned ATC values. In
return of the request of CPACE-HCE EMV processing the key database delivers the session
key with the lowest assigned ATC value and the assigned ATC value to CPACE-HCE EMV
processing. If no session key is left CPACE-HCE EMV processing is informed that no
session key is left.
Within this request CPACE-HCE EMV processing indicates whether the session key shall
be deleted in its key database after the delivery or whether it needs to have the option to
request this key just once more. In any case if a session key is delivered all session keys
with a lower assigned ATC shall be deleted.
Based on the request the key database delivers the number of session keys still not used
stored in the key database (Key Counter) for a requested Digital Card. In particular even if a
session key is not deleted due to the option to request the same key just once more it is
never included in the number of session keys still stored in the key database of a Digital
Card.
CPACE for Host Card Emulation Handling of symmetric keys Version 1.0 Second GENERATE AC Command
15.03.2019 Page 104 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If IO4 is supported the key database also delivers x Days Valid Key Counters for x = 0,
x = Trigger Replenishment Number of Days and x = Force Replenishment Number of Days
defined by Key Validity Number of Days.
If IO4 is supported and the Key Validity Number of Days have not been provisioned for a
Digital Card, then the default value '00 00' will be used, i.e. the key data base only delivers
the 0 Days Valid Key Counter in addition to the Key Counter.
If IO4 is not supported, the replenishment of session keys can be triggered by the Mobile
Payment App or the HCE Server based on the Key Counter and the Key Counter Limits
defined by the issuer for a Digital Card:
If Key Counter < Trigger Replenishment Limit the replenishment shall be triggered.
If Key Counter < Force Replenishment Limit the replenishment shall be triggered and
if the connection to the HCE Server is not possible the Mobile Payment App shall
indicate to the cardholder that an online connection to the HCE Server is necessary
to receive new keys.
If IO4 is supported the replenishment of session keys can be triggered by the Mobile
Payment App or the HCE Server based on the x Days Valid Key Counter(s) and the Key
Counter Limits defined by the issuer for a Digital Card:
If x Days Valid Key Counter < Trigger Replenishment Limit the replenishment shall
be triggered, where x = Trigger Replenishment Number of Days or, if Key Validity
Number of Days have not been provisioned, x = 0.
If x Days Valid Key Counter < Force Replenishment Limit the replenishment shall be
triggered and if the connection to the HCE Server is not possible the Mobile Payment
App shall indicate to the cardholder that an online connection to the HCE Server is
necessary to receive new keys, where x = Force Replenishment Number of Days or,
if Key Validity Number of Days have not been provisioned, x = 0.
New session keys delivered to the key database for a Digital Card are only added to the key
database and do not delete automatically already stored session keys for the Digital Card.
CPACE for Host Card Emulation Data Model Version 1.0 Data of a Digital Card
15.03.2019 Page 105 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
11 Data Model
11.1 Data of a Digital Card
Several Digital Cards may be supported by the HCE SDK.
Req C.117 Identification of Digital Cards
Digital Cards have to be identified unambiguously within the HCE SDK for internal access of
CPACE-HCE EMV processing, Digital Card Handling, Mobile Payment App or HCE Server.
This specification does not prescribe the format of the Digital Card ID or when to assign the
identifier to a Digital Card. But it is assumed that Digital Cards can be identified
unambiguously after they have been provisioned.
The data of a Digital Card consists of persistent and transient data.
Persistent data defines the Digital Card and controls its processing:
Configuration Data which configures CPACE-HCE EMV processing and/or Mobile
Payment App processing. Configuration Data is set by the issuer and may be updated
by the issuer via HCE Server. If IO1 is supported, the Configuration Data items No
CVM MaxAmount, No CVM MaxNumber and Number of Days Without CHV Limit may
also be updated by the issuer with a second GENERATE AC command. With the
exception of No CVM MaxAmount, No CVM MaxNumber and Number of Days
Without CHV Limit, which may be changed by the second GENERATE AC command,
Configuration Data is not changed by CPACE-HCE EMV processing.
Dynamic Data which is changed by CPACE-HCE EMV processing functions, e.g. No
CVM Accumulator or No CVM Counter. Dynamic Data is initialised by CPACE-HCE
EMV processing or by the issuer. Some Dynamic Data items may also be updated by
the issuer via HCE Server. If IO1 is supported, the Dynamic Data items No CVM
Accumulator, No CVM Counter and Last CHV Date in Days may also be updated by
the issuer with a second GENERATE AC command.
Card Data which is defined for the Digital Card to be read during Read Application
Data (see Section 7), but not used by CPACE-HCE EMV processing or Mobile
Payment App processing. Card Data is set by the issuer and may be updated by the
issuer via HCE Server.
Cryptographic keys securely stored in a key database according to Req C.116.
The Mobile Payment App and the HCE Server are allowed to read all persistent data defined
for a Digital Card with the exception of the cryptographic keys.
Some persistent data items, called Device Configuration Data, may be set and updated by
the Mobile Payment App, possibly according to options and restrictions defined by the issuer.
Configuration Data is listed in Table 25. In addition, for each data item it is indicated in the
column "Provision" in Table 25 whether it is mandatory, conditional or optional to deliver this
data item within the provisioning of a Digital Card.
CPACE for Host Card Emulation Data Model Version 1.0 Data of a Digital Card
15.03.2019 Page 106 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If provisioning of a Configuration Data item is conditional, then the respective condition is
described in the definition of the data item in Section 12. If provisioning of a Configuration
Data item is optional, then the definition of the data item in Section 12 explains how CPACE-
HCE EMV processing handles the case that the data item is not provisioned.
Dynamic Data is listed in Table 26. In addition, for each data item, it is indicated in the
column "Provision" in Table 26 whether it is conditional, optional or not supported to deliver
an initial value for this data item within the provisioning of a Digital Card.
If provisioning of the initial value of a Dynamic Data item is conditional, then the respective
condition is described in the definition of the data item in Section 12. If provisioning of the
initial value of a Dynamic Data item is optional or not supported, then the definition of the
data item in Section 12 explains how CPACE-HCE EMV processing handles the case that
the data item is not provisioned.
Device Configuration Data and the conditions under which the respective data item may be
updated by the Mobile Payment App is listed in Table 27.
Card Data is not listed in this specification, since it is neither used nor stored by CPACE-
HCE EMV processing or Mobile Payment App processing.
Transient data is used by CPACE-HCE EMV processing and has a lifetime restricted to an
EMV transaction:
Transaction Data which is received/provided by CPACE-HCE EMV processing over
the contactless interface in command/response data fields of GET PROCESSING
OPTIONS and/or GENERATE AC commands or which is received by CPACE-HCE
EMV processing from the Mobile Payment App,
Internal Working Variables which are initialised, set, updated internally by CPACE-
HCE EMV processing functions.
Transaction Data is listed in Table 28. The entries in the column "Source" in Table 28
indicate, whether the respective data item is:
received by CPACE-HCE EMV processing over the contactless interface (TA-T),
provided by CPACE-HCE EMV processing over the contactless interface (TA-C),
received by CPACE-HCE EMV processing from the Mobile Payment App (TA-M).
The tags assigned to some of the Transaction Data items according to the column "Tag" in
Table 28 are defined by EMV or, for Cardholder Verification and Confirmation Status
(CHV&CS) and Online Parameter, by this specification. The tags assigned to Transaction
Data elements provided by CPACE-HCE EMV processing over the contactless interface (TA-
C) have to be used in the respective response data fields nested in a template with tag '77', if
this is applicable according to the column "Template" in Table 28. With the exception of the
tag '83' assigned to PDOL Related Data, which is used in the GET PROCESSING OPTIONS
command data field, the tags assigned to Transaction Data elements received by CPACE-
HCE EMV processing over the contactless interface (TA-T) are listed in Table 28 for
information only.
CPACE for Host Card Emulation Data Model Version 1.0 Data of a Digital Card
15.03.2019 Page 107 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Internal Working Variables are listed in Table 29.
Data Item Name Provision
AID Table
AID Entry
Mandatory
AIP/AFL Entries
AIP/AFL Entry x
Mandatory
Application Control Mandatory
Cardholder CHC Limit Optional
Cardholder CHV Limit Optional
Cardholder CHV&C Control Optional
Cardholder Confirmation Timeout Conditional
Cardholder Confirmation Usage Limit Conditional
CDCVM Cardholder Verification Timeout Conditional
CDCVM Cardholder Verification Usage Limit Conditional
Default Issuer Application Data (IAD) Optional
Dynamic Issuer Data Optional
GPO Parameters
GPO Parameters x
Mandatory
Issuer CHC Limit Optional
Issuer CHV Limit Conditional
Issuer CHV&C Control Conditional
Issuer Options Profile Controls
Issuer Options Profile Control x
Mandatory
Key Counter Limits Mandatory
Key Validity Number of Days (if IO4 is supported) Optional
No CVM Accumulator Control Conditional
No CVM Accumulator Profile Controls
No CVM Accumulator Profile Control x
Conditional
No CVM Counter Control Conditional
No CVM Counter Profile Controls
No CVM Counter Profile Control x
Conditional
No CVM MaxAmount Conditional
No CVM MaxNumber Conditional
Number of Days Without CHV Limit Conditional
Profile Control Table
Profile Control x
Mandatory
Profile Selection Table
Profile Selection Entry
Conditional
Second Presentment Timeout Conditional
CPACE for Host Card Emulation Data Model Version 1.0 Data of a Digital Card
15.03.2019 Page 108 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Data Item Name Provision
Static Issuer Data Optional
UI Module Data
UI Module Data Entry x
Optional
Table 25: Configuration Data of a Digital Card
Data Item Name Provision
CHV Required for Next Transaction Optional
Key Counter Not supported
Last CHV Date in Days Conditional
No CVM Accumulator Conditional
No CVM Counter Conditional
Previous Transaction History (PTH) (if IO1 is supported) Not supported
Transaction History Not supported
x Days Valid Key Counter Not supported
Table 26: Dynamic Data of a Digital Card
Data Item Name Condition for Update by Mobile Payment App
Cardholder CHC Limit If 'Cardholder CHC Limit' in Issuer CHV&C Control =
APPLICABLE.
Cardholder CHV Limit If 'Cardholder CHV Limit' in Issuer CHV&C Control =
APPLICABLE.
Cardholder CHV&C Control If 'Cardholder Forced 2nd Presentment Setting' in
Issuer CHV&C Control = APPLICABLE.
CHV Required for Next Transaction none
Dynamic Issuer Data If a value is provided for the data element during the
provisioning of the Digital Card. The length of the
data element shall not be changed.
Table 27: Device Configuration Data of a Digital Card
Data Item Name Source Template Tag
Amount, Authorised TA-T - '9F02'
Amount, Other TA-T - '9F03'
Application Cryptogram TA-C '77' '9F26'
Application Transaction Counter (ATC) TA-C '77' '9F36'
Authorisation Response Code TA-T - '8A'
Card Status Update (CSU) TA-T - -
Card Verification Results (CVR) TA-C - -
Cardholder Confirmation Data TA-M - -
Cardholder Verification and Confirmation Status (CHV&CS) TA-C '77' 'DF4B'
CPACE for Host Card Emulation Data Model Version 1.0 Data of a Digital Card
15.03.2019 Page 109 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Data Item Name Source Template Tag
Cardholder Verification Data TA-M - -
Cardholder Verification Method (CVM) Results TA-T - '9F34'
Cryptogram Information Data (CID) TA-C '77' '9F27'
Issuer Application Data (IAD) TA-C '77' '9F10'
Issuer Authentication Data (IATD) TA-T - '91'
No CVM Accumulator Balance TA-C - -
Online Parameter TA-C '77' '9F55'
PDOL Related Data TA-T - '83'
Proprietary Authentication Data (PAD) TA-T - -
Recent Cardholder Confirmation TA-M - -
Recent CDCVM Cardholder Verification TA-M - -
Terminal Country Code TA-T - '9F1A'
Terminal Type TA-T - '9F35'
Terminal Risk Management Data TA-T - '9F1D'
Terminal Verification Results (TVR) TA-T - '95'
Transaction Currency Code TA-T - '5F2A'
Transaction Date TA-T - '9A'
Transaction Type TA-T - '9C'
Unpredictable Number TA-T - '9F37'
Table 28: Transaction Data
Data Item Name
AID Selected
CHC Limit
CHV Limit
CHV Required for This Transaction
GPO Input Data
GPO Input Data Length
Issuer Options Profile Control
No CVM Accumulator Profile Control
No CVM Counter Profile Control
Profile Control
Profile ID
Restart Flag
Transaction Amount
Transaction CVM
Table 29: Internal Working Variables
CPACE for Host Card Emulation Data Model Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 110 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
11.2 Provisioning and Update of a Digital Card
For provisioning and update of a Digital Card, the issuer provides to the HCE Server a set of
Card Data, Configuration Data and Dynamic Data (called personalisation data) that are
grouped by standardised DGIs. In which format the personalisation data is transferred from
the HCE Server to the Digital Card Handling is out of scope for this specification and is up to
the Implementer. Table 30 gives an overview over the DGIs used for grouping
personalisation data.
Note:
During Read Application Data (see Section 7), the terminal reads the Card Data
necessary to process the transaction. This data is organised in grouped records which
are referenced by an SFI (identifying the group) and a record number (identifying the
individual record in the respective group). For provisioning of Card Data the DGIs with
Tag '0XYY' are used, where '0X' with 'X' <= 'A' is the SFI and 'YY' is the record number.
The tags assigned to some of the data items are used to identify and reference the
respective data elements and templates for personalisation. The defined tags neither have
to be used for the respective data item within CPACE-HCE EMV processing nor have these
tags to be stored for the respective data item within the Digital Card.
DGI Description Provision
'0XYY' Card Data to be read with READ RECORD
using SFI '0X' (X <= 'A') and record number 'YY'
Optional
'1A01' - '1AXX' Profile Selection Table: Profile Selection Entries '01' - 'XX' Conditional
'1B01' - '1B0X' AID Table: AID Entries '01' - '0X' Mandatory
CPACE for Host Card Emulation Data Model Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 111 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
DGI Description Provision
'3000' Card Internal Data Elements
Default Issuer Application Data (IAD) ('9F10') Optional
Application Control ('C1') Mandatory
Static Issuer Data ('D0') Optional
Dynamic Issuer Data ('D1') Optional
Issuer CHV&C Control ('D9') Conditional
Cardholder Confirmation Timeout ('DA') Conditional
Second Presentment Timeout ('DB') Conditional
Cardholder CHV&C Control ('DC') Optional
CHV Required for Next Transaction ('DD') Optional
CDCVM Cardholder Verification Timeout ('DE') Conditional
Number of Days Without CHV Limit ('C3') Conditional
Last CHV Date in Days ('D2') Conditional
CDCVM Cardholder Verification Usage Limit ('DF01') Conditional
Cardholder Confirmation Usage Limit ('DF02') Conditional
'3F30' No CVM Accumulator ('DF01') and
No CVM MaxAmount ('DF11')2)
Conditional
'3F31' No CVM Accumulator Profile Controls:
No CVM Accumulator Profile Control x ('DF0X')3)
Conditional
'3F32' No CVM Accumulator Control ('DF01') Conditional
'3F35' No CVM Counter ('DF01') and
No CVM MaxNumber ('DF11')4)
Conditional
'3F36' No CVM Counter Profile Controls:
No CVM Counter Profile Control x ('DF0X')3)
Conditional
'3F37' No CVM Counter Control ('DF01') Conditional
'3F3B' Issuer Options Profile Controls:
Issuer Options Profile Control x ('DF0X')3)
Mandatory
'3F3C' Issuer CHC Limit ('DF01') Optional
Issuer CHV Limit ('DF02') Conditional
Cardholder CHC Limit ('DF04') Optional
Cardholder CHV Limit ('DF05') Optional
2) The No CVM Accumulator is personalised using the tag 'DF01' and the No CVM MaxAmount is personalised using the
tag 'DF11'. The conditions requiring provisioning of the No CVM Accumulator and the conditions requiring provisioning
of the No CVM MaxAmount are the same. Therefore, both data items have to be provisioned together or none of the
two is provisioned.
3) Since the data item is a numbered list the entries of the data item are personalised using the tags 'DF0X' or 'DFXX'
where '0X' or 'XX' indicates the associated number of the entry.
4) The No CVM Counter is personalised using the tag 'DF01' and the No CVM MaxNumber is personalised using the tag
'DF11'. The conditions requiring provisioning of the No CVM Counter and the conditions requiring provisioning of the
No CVM MaxNumber are the same. Therefore, both data items have to be provisioned together or none of the two is
provisioned.
CPACE for Host Card Emulation Data Model Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 112 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
DGI Description Provision
Key Counter Limits ('DF03') Mandatory
Key Validity Number of Days ('DF06') (if IO4 is supported) Optional
'3F3E' GPO Parameters:
GPO Parameters x ('DFXX')3)
Mandatory
'3F3F' Profile Control Table:
Profile Control x ('DFXX')3)
Mandatory
'3F41' AIP/AFL Entries:
AIP/AFL Entry x ('DF0X')3)
Mandatory
'407x' UI Module Data:
UI Module Data Entry x
Optional
'8000' or '8002' Master Keys Mandatory
'9000' or '9002' Key Check Value Optional
Table 30: DGIs - Overview
CPACE for Host Card Emulation Data Dictionary Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 113 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12 Data Dictionary
This section contains the description of data items which are used and/or stored by CPACE-
HCE EMV processing. These data items are listed in Table 31.
The data items listed in this section are classified into the categories defined in Section 11.1.
The following abbreviations are used in column "Category" in Table 31:
Configuration Data: CD,
Dynamic Data: DD,
Transaction Data
received by CPACE-HCE EMV processing over the contactless interface: TA-T,
provided by CPACE-HCE EMV processing over the contactless interface: TA-C,
received by CPACE-HCE EMV processing from the Mobile Payment App: TA-M,
Internal Working Variable: IWV,
Device Configuration Data: DC.
A sub data item has the same category as the data item it is included in.
The tags assigned to some of the Transaction Data items (column "Tag" in Table 31) are
defined by EMV or, for Cardholder Verification and Confirmation Status (CHV&CS) and
Online Parameter, by this specification (see Section 11.1). Transaction Data elements
provided by CPACE-HCE EMV processing over the contactless interface (TA-C) are not only
tagged but also nested in a template (Response Message Template) with tag '77' (column
"Template" in Table 31).
For Configuration Data items, it is indicated in this section whether delivery of the respective
data item is mandatory, conditional or optional within the provisioning of a Digital Card. For
Dynamic Data items, it is indicated whether delivery of an initial value of the respective data
item is conditional, optional or not supported within the provisioning of a Digital Card. The
following abbreviations are used in column "Provision" in Table 31:
mandatory: M
conditional: C
optional: O
not supported: No
Note:
Card Data which is neither used nor stored by CPACE-HCE EMV processing or Mobile
Payment App processing according to its definition in Section 11 is not listed in this
section.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 114 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Data Item Name Template Tag Category Provision
AID Selected - - IWV -
AID Table
AID Entry
- - CD M
AIP/AFL Entries
AIP/AFL Entry x
- - CD M
Amount, Authorised - '9F02' TA-T -
Amount, Other - '9F03' TA-T -
Application Control - - CD M
Application Cryptogram '77' '9F26' TA-C -
Application Transaction Counter (ATC) '77' '9F36' TA-C -
Authorisation Response Code - '8A' TA-T -
Card Status Update (CSU) - - TA-T -
Card Verification Results (CVR) - - TA-C -
Cardholder CHC Limit - - CD, DC O
Cardholder CHV Limit - - CD, DC O
Cardholder CHV&C Control - - CD, DC O
Cardholder Confirmation Data - - TA-M -
Cardholder Confirmation History (part of
Transaction History)
- - DD No
Cardholder Confirmation Timeout - - CD C
Cardholder Confirmation Usage Limit - - CD C
Cardholder Verification and Confirmation Status
(CHV&CS)
'77' 'DF4B' TA-C -
Cardholder Verification Data - - TA-M -
Cardholder Verification Method (CVM) Results - '9F34' TA-T -
CDCVM Cardholder Verification History (part of
Transaction History)
- - DD No
CDCVM Cardholder Verification Timeout - - CD C
CDCVM Cardholder Verification Usage Limit - - CD C
CHC Limit - - IWV -
CHV Limit - - IWV -
CHV Required for Next Transaction - - DD, DC O
CHV Required for This Transaction - - IWV -
Cryptogram Information Data (CID) '77' '9F27' TA-C -
Default Issuer Application Data (IAD) - - CD O
Dynamic Issuer Data - - CD, DC O
GPO Input Data - - IWV -
GPO Input Data Length - - IWV -
GPO Parameters
GPO Parameters x
- - CD M
Issuer Application Data (IAD) '77' '9F10' TA-C -
Issuer Authentication Data (IATD) - '91' TA-T -
CPACE for Host Card Emulation Data Dictionary Version 1.0 Provisioning and Update of a Digital Card
15.03.2019 Page 115 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Data Item Name Template Tag Category Provision
Issuer CHC Limit - - CD O
Issuer CHV Limit - - CD C
Issuer CHV&C Control - - CD C
Issuer Options Profile Control - - IWV -
Issuer Options Profile Controls
Issuer Options Profile Control x
- - CD M
Key Counter - - DD No
Key Counter Limits - - CD M
Key Validity Number of Days - - CD O
Last CHV Date in Days - - DD C
No CVM Accumulator - - DD C
No CVM Accumulator Balance - - TA-C -
No CVM Accumulator Control - - CD C
No CVM Accumulator Profile Control - - IWV -
No CVM Accumulator Profile Controls
No CVM Accumulator Profile Control x
- - CD C
No CVM Counter - - DD C
No CVM Counter Control - - CD C
No CVM Counter Profile Control - - IWV -
No CVM Counter Profile Controls
No CVM Counter Profile Control x
- - CD C
No CVM MaxAmount - - CD C
No CVM MaxNumber - - CD C
Number of Days Without CHV Limit - - CD C
Online Parameter '77' '9F55' TA-C -
PDOL Related Data - '83' TA-T -
Previous Transaction History (PTH) - - DD No
Profile Control - - IWV -
Profile Control Table
Profile Control x
- - CD M
Profile ID - - IWV -
Profile Selection Table
Profile Selection Entry
- - CD C
Proprietary Authentication Data (PAD) - - TA-T -
Recent Cardholder Confirmation - - TA-M -
Recent CDCVM Cardholder Verification - - TA-M -
Restart Flag - - IWV -
Restart Indicator (part of Transaction History) - - DD No
Second Presentment Indicator (part of
Transaction History)
- - DD No
Second Presentment Timeout - - CD C
CPACE for Host Card Emulation Data Dictionary Version 1.0 AID Selected
15.03.2019 Page 116 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Data Item Name Template Tag Category Provision
Static Issuer Data - - CD O
Terminal Country Code - '9F1A' TA-T -
Terminal Risk Management Data - '9F1D' TA-T -
Terminal Type - '9F35' TA-T -
Terminal Verification Results (TVR) - '95' TA-T -
Time of First Presentment (part of Transaction
History)
- - DD -
Transaction Amount - - IWV -
Transaction Currency Code - '5F2A' TA-T -
Transaction CVM - - IWV -
Transaction Date - '9A' TA-T -
Transaction History - - DD No
Transaction Type - '9C' TA-T -
Unpredictable Number - '9F37' TA-T -
UI Module Data
UI Module Data Entry x
- - CD O
Table 31: Data Items Used and/or Stored by CPACE-HCE EMV processing
12.1 AID Selected
Template: -
Tag: -
Length (in bytes): 5-16
Format: b
Category: Internal Working Variable
Description: The AID Selected is an internal working variable used to store the AID
which has been selected for the current transaction with the SELECT
command.
Note:
The Digital Card to which the AID Selected is assigned is the currently
selected Digital Card.
CPACE for Host Card Emulation Data Dictionary Version 1.0 AID Table
15.03.2019 Page 117 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.2 AID Table
Template: -
Tag: -
Length (in bytes): not applicable
Format: List
Category: Configuration Data
Provision: Mandatory
Description: The AID Table is an internal list with all AID Entries assigned to the AIDs
assigned to a Digital Card.
12.2.1 AID Entry
Template: -
Tag: -
Length (in bytes): var.
Format: b
Category: Configuration Data
Provision: Mandatory
Description: An AID Entry is the concatenation of the TLV coded data objects listed in
Table 32, which also defines whether a data objects is mandatory or
optional.
At least one AID Entry shall be provided within the provisioning of a Digital
Card.
The mandatory data objects shall be present in the AID Entry in the
sequence indicated in Table 32. If the GPO Parameters Reference is
present, then it shall be the last data object in the AID Entry.
The DF Names contained in the AID Entry must be identical with (one of)
the AIDs assigned to the Digital Card.
The same DF Name shall not be contained in two AID Entries assigned to
the same Digital Card.
In addition, the following rule in Section 12.3.1 of [EMV 1] applies to
DF Names in the AID Entries which begin with the same sub-AID:
All DF Names beginning with the same sub-DF Name must be
distinguished by adding unique data to this common sub-DF Name.
All DF Names beginning with the same sub-DF Name must be longer
than this common sub-DF Name.
This rule must be observed by the issuer of the Digital Card. Correct
processing of CPACE-HCE EMV processing relies on adherence to this
rule. But CPACE-HCE EMV processing does not check whether it has
been observed by the issuer.
CPACE for Host Card Emulation Data Dictionary Version 1.0 AIP/AFL Entries
15.03.2019 Page 118 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If the GPO Parameters Reference is absent from the AID Entry, then the
default value '01' shall be used as GPO Parameters Reference for the AID
Entry.
Tag Length
(in bytes) Format Value Presence
'84' 5-16 b DF Name (AID) Mandatory
'A5' var. b FCI Proprietary Template Mandatory
'61' var. b PPSE Directory Entry Mandatory
'C1' 1 b GPO Parameters Reference, binary value in the
range from '01' to '7F'
Optional
Table 32: Data Objects in the AID Entry
12.3 AIP/AFL Entries
Template: -
Tag: -
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Mandatory
Description: AIP/AFL Entries is a numbered list of up to 15 AIP/AFL Entry x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 AIP/AFL Entries
15.03.2019 Page 119 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.3.1 AIP/AFL Entry x
Template: -
Tag: -
Length (in bytes): var. up to 63
Format: b
Category: Configuration Data
Provision: Mandatory
Description: AIP/AFL Entry x indicates the issuer's choice of AIP and AFL used in
Initiate Application Processing to generate the response to the GET
PROCESSING OPTIONS command for all Profiles using this AIP/AFL
Entry x.
The number x may have any integer value between 1 and 15.
At least one AIP/AFL Entry x shall be provided within the provisioning of a
Digital Card.
The AIP indicates the capabilities of the Digital Card to support specific
functions and is coded as described in Table 33.
The AIP/AFL Entry x used for the transaction is identified in the Profile
Control. If the AIP/AFL ID in the Profile Control = x, then AIP/AFL Entry x
will be used for the transaction.
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x - - - - - RFU/Not Used
- - - x - - - - Cardholder Verification Supported
- - - 0 - - - - Cardholder Verification is not Supported
- - - 1 - - - - Cardholder Verification is Supported
- - - - 1 - - - Terminal Risk Management is to be Performed (Fixed
Value)
- - - - - 0 - - Issuer Authentication using EXTERNAL
AUTHENTICATE is not Supported (Fixed Value)
- - - - - - x - CDCVM Cardholder Verification Supported
- - - - - - 0 - CDCVM Cardholder Verification is not Supported
- - - - - - 1 - CDCVM Cardholder Verification is Supported
- - - - - - - x Not Used
2 1 - - - - - - - EMV Mode is Supported (Fixed Value)
- x x x x x x - RFU
- - - - - - - 0 Relay Resistance Protocol is not Supported (Fixed
Value)
Table 33: Application Interchange Profile (AIP) Coding
Bytes 1-2 Byte 3 Bytes 4-63
AIP x AFL x Length AFL x
CPACE for Host Card Emulation Data Dictionary Version 1.0 Amount, Authorised
15.03.2019 Page 120 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Table 34: AIP/AFL Entry x Coding
12.4 Amount, Authorised
Template: -
Tag: '9F02'
Length (in bytes): 6
Format: n 12
Category: Transaction Data received over the contactless interface
Description: Authorised amount of the transaction (excluding adjustments).
12.5 Amount, Other
Template: -
Tag: '9F03'
Length (in bytes): 6
Format: n 12
Category: Transaction Data received over the contactless interface
Description: Secondary amount associated with the transaction representing a
cashback amount.
12.6 Application Control
Template: -
Tag: -
Length (in bytes): 4
Format: b
Category: Configuration Data
Provision: Mandatory
Description: Application Control activates or de-activates functions of CPACE-HCE
EMV processing.
Bits b4 through b1 of byte 4 are defined by this specification.
Application Control is coded as shown in Table 35.
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x - - Not Used
- - - - - - x - CDCVM Cardholder Verification Supported
- - - - - - 0 - CDCVM Cardholder Verification not Supported
- - - - - - 1 - CDCVM Cardholder Verification Supported
- - - - - - - x Not Used
CPACE for Host Card Emulation Data Dictionary Version 1.0 Application Cryptogram
15.03.2019 Page 121 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
2 x x x x - - - - RFU/Not Used
- - - - x - - - Activate Profile Selection Table
- - - - 0 - - - Do not Activate Profile Selection Table
- - - - 1 - - - Activate Profile Selection Table
- - - - - x - - Amounts Included in CDOL2
- - - - - 0 - - Amounts not Included in CDOL2
- - - - - 1 - - Amounts Included in CDOL2
- - - - - - x x RFU
3 x x x x x x x - RFU/Not Used
4 x x x x x x x x RFU/Not Used
Table 35: Application Control Coding
12.7 Application Cryptogram
Template: -
Tag: '9F26'
Length (in bytes): 8
Format: b
Description: Cryptogram returned by CPACE-HCE EMV processing in response to the
GENERATE AC command.
12.8 Application Transaction Counter (ATC)
Template: -
Tag: '9F36'
Length (in bytes): 2
Format: b
Description: Counter provided by the key database of the Digital Card for the
transaction and returned by CPACE-HCE EMV processing in response to
the GENERATE AC command.
12.9 Authorisation Response Code
Template: -
Tag: '8A'
Length (in bytes): 2
Format: an 2
Category: Transaction Data received over the contactless interface
Description: Code that defines the disposition of a message. For details, see [EMV 4],
Annex A, Table 34
CPACE for Host Card Emulation Data Dictionary Version 1.0 Card Status Update (CSU)
15.03.2019 Page 122 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.10 Card Status Update (CSU)
Template: -
Tag: -
Length (in bytes): 4
Format: b
Category: Transaction Data received over the contactless interface
Description: Card Status Update (CSU) contains data sent to CPACE-HCE EMV
processing by the issuer of the Digital Card to indicate whether the issuer
approves or declines the transaction, and to initiate actions specified by
the issuer.
According to this specification, Card Status Update (CSU) is coded as
shown in Table 36.
The interpretation of 'Update No CVM Accumulator (and No CVM
Counter)' in byte 2 of Card Status Update (CSU) depends on the value of
'Individual Update of No CVM Accumulator and No CVM Counter' in byte
4 of Card Status Update (CSU):
If 'Individual Update of No CVM Accumulator and No CVM
Counter' in byte 4 of Card Status Update (CSU) has the value 0b,
then 'Update No CVM Accumulator (and No CVM Counter)' in byte
2 of Card Status Update (CSU) applies to No CVM Accumulator
and No CVM Counter.
If 'Individual Update of No CVM Accumulator and No CVM
Counter' in byte 4 of Card Status Update (CSU) has the value 1b,
then 'Update No CVM Accumulator (and No CVM Counter)' in byte
2 of Card Status Update (CSU) only applies to the No CVM
Accumulator. The No CVM Counter shall be updated as indicated
in 'Update No CVM Counter' in byte 4 of Card Status Update
(CSU).
CPACE for Host Card Emulation Data Dictionary Version 1.0 Card Status Update (CSU)
15.03.2019 Page 123 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x - - - - - - - Proprietary Authentication Data (PAD) Included
0 - - - - - - - PAD not Included
1 - - - - - - - PAD Included
- x x x - - - - RFU
- - - - x x x x Not Used
2 x - - - - - - - Issuer Approves Online Transaction
0 - - - - - - - Issuer Declines Online Transaction
1 - - - - - - - Issuer Approves Online Transaction
- x x x x x - - Not Used
- - - - - - x x Update No CVM Accumulator (and No CVM Counter)
- - - - - - 0 0 Do Not Update
- - - - - - 0 1 Set to No CVM MaxAmount5)
(and No CVM MaxNumber
5))
- - - - - - 1 0 Reset to Zero
- - - - - - 1 1 Not Used
3 x x x x x x x x New No CVM MaxNumber or filler6)
4 x - - - - - - - Individual Update of No CVM Accumulator and No CVM Counter
0 - - - - - - - Update of No CVM Accumulator and No CVM Counter as indicated in byte 2, bits b2-b1
1 - - - - - - - Individual Update of No CVM Accumulator as indicated in byte 2, bits b2-b1,and of No CVM Counter as indicated in byte 4, bits b4-b3
- x - - - - - - New Number of Days Without CHV Limit in PAD
- 0 - - - - - - No New Number of Days Without CHV Limit in PAD
- 1 - - - - - - New Number of Days Without CHV Limit in PAD
- - x - - - - - New No CVM MaxAmount in PAD
- - 0 - - - - - No New No CVM MaxAmount in PAD
- - 1 - - - - - New No CVM MaxAmount in PAD
- - - x - - - - New No CVM MaxNumber in byte 3
- - - 0 - - - - No New No CVM MaxNumber in byte 3
- - - 1 - - - - New No CVM MaxNumber in byte 3
- - - - x x - - Update No CVM Counter
- - - - 0 0 - - Do Not Update
- - - - 0 1 - - Set No CVM Counter to No CVM MaxNumber5)
- - - - 1 0 - - Reset No CVM Counter to Zero
- - - - 1 1 - - Not Used
- - - - - - x - Update Last CHV Date in Days
- - - - - - 0 - Do not Update
- - - - - - 1 - Set Last CHV Date in Days to Transaction Date
- - - - - - - x Not Used
Table 36: Card Status Update (CSU) Coding
5) If a new No CVM MaxAmount and/or No CVM MaxNumber is provided in the PAD and/or Card Status Update (CSU),
then the No CVM Accumulator and/or No CVM Counter shall be set to the new maximum value.
6) The value of this byte is ignored by CPACE-HCE EMV processing if 'New No CVM MaxNumber' in byte 4 of Card
Status Update (CSU) has the value 0b.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Card Verification Results (CVR)
15.03.2019 Page 124 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.11 Card Verification Results (CVR)
Template: -
Tag: -
Length (in bytes): 5
Format: b
Category: Transaction Data
Description: Card Verification Results (CVR) are used to inform the issuer about
exception conditions that occurred during the current and previous
transactions. It is transmitted to the issuer in the Issuer Application Data
(IAD).
Card Verification Results (CVR) are coded as shown in Table 37.
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x - - - - - - AC Type Returned in Second GENERATE AC
0 0 - - - - - - AAC
0 1 - - - - - - TC
1 0 - - - - - - Second GENERATE AC Not requested
1 1 - - - - - - RFU
- - x x - - - - AC Type Returned in First GENERATE AC
- - 0 0 - - - - AAC
- - 0 1 - - - - Not Used
- - 1 0 - - - - ARQC
- - 1 1 - - - - RFU
- - - - x x - - Not Used
- - - - - - x - Issuer Authentication Not Performed (If IO1 supported)
- - - - - - 0 - Issuer Authentication Performed (If IO1 supported)
- - - - - - 1 - Issuer Authentication Not Performed (If IO1 supported)
- - - - - - - x Issuer Authentication Failed (If IO1 supported)
- - - - - - - 0 Issuer Authentication Did not Fail (If IO1 supported)
- - - - - - - 1 Issuer Authentication Failed (If IO1 supported)
2 x x x x - - - - Not Used
- - - - x - - - CDCVM Cardholder Verification Performed
- - - - 0 - - - CDCVM Cardholder Verification Not Performed
- - - - 1 - - - CDCVM Cardholder Verification Performed
- - - - - x - - Reserved
- - - - - - x x Not Used
CPACE for Host Card Emulation Data Dictionary Version 1.0 Card Verification Results (CVR)
15.03.2019 Page 125 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
3 x - - - - - - - No CVM MaxNumber Exceeded
0 - - - - - - - No CVM MaxNumber not Exceeded
1 - - - - - - - No CVM MaxNumber Exceeded
- x - - - - - - Not Used
- - x - - - - - No CVM MaxAmount Exceeded
- - 0 - - - - - No CVM MaxAmount not Exceeded
- - 1 - - - - - No CVM MaxAmount Exceeded
- - - x x - - - Not Used
- - - - - x - - Terminal (Erroneously) Considers Offline PIN OK
- - - - - 0 - - Terminal Does not Consider Offline PIN OK
- - - - - 1 - - Terminal (Erroneously) Considers Offline PIN OK
- - - - - - x - Check Failed
- - - - - - 0 - No Check Failed
- - - - - - 1 - Check Failed
- - - - - - - x Not Used
4 x x x x x x x x Not Used
5 x - - - - - - - CHV Required on Next Transaction
0 - - - - - - - CHV not Required on Next Transaction
1 - - - - - - - CHV Required on Next Transaction
- x - - - - - - CHV Limit Exceeded
- 0 - - - - - - CHV Limit not Exceeded
- 1 - - - - - - CHV Limit Exceeded
- - x - - - - - Number of Days Without CHV Limit Exceeded
- - 0 - - - - - Number of Days Without CHV Limit not Exceeded
- - 1 - - - - - Number of Days Without CHV Limit exceeded
- - - x - - - - Cardholder Confirmation Performed
- - - 0 - - - - Cardholder Confirmation not Performed
- - - 1 - - - - Cardholder Confirmation Performed
- - - - x - - - 2nd Presentment Performed
- - - - 0 - - - 2nd Presentment not Performed (1st Presentment)
- - - - 1 - - - 2nd Presentment Performed
- - - - - x x x RFU
Table 37: Card Verification Results (CVR) Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder CHC Limit
15.03.2019 Page 126 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.12 Cardholder CHC Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Configuration Data and Device Configuration Data
Provision: Optional
Description: If present for the Digital Card and applicable according to Issuer CHV&C
Control, the Cardholder CHC Limit is the cardholder defined limit for the
transaction amount, below which cardholder confirmation is not required.
The currency code and the currency conversion table - if any - applicable
to this limit are defined in Issuer CHV&C Control.
The Cardholder CHC Limit is Device Configuration Data, i.e. it may be set
and updated by the Mobile Payment App.
The Cardholder CHC Limit is evaluated according to the following rules
(see Req C.63):
'Cardholder CHC Limit' in Issuer CHV&C Control indicates, whether
Cardholder CHC Limit is to be used for the Digital Card.
If the issuer has chosen to not provide Issuer CHV&C Control or to set
'Cardholder CHC Limit' in Issuer CHV&C Control = NOT
APPLICABLE, then the value of Cardholder CHC Limit will have no
effect. Therefore the Mobile Payment App should not offer an option to
the cardholder to set or update this limit, if 'Cardholder CHC Limit' in
Issuer CHV&C Control = NOT APPLICABLE.
If the issuer has chosen to set 'Cardholder CHC Limit' in Issuer
CHV&C Control = APPLICABLE, then the value of Cardholder CHC
Limit will have no (additional) effect if its value is greater than or equal
to the Issuer CHC Limit. This should be taken into account when the
Mobile Payment App offers an option to the cardholder to set or
update this limit.
If the issuer has chosen to set 'Cardholder CHC Limit' in Issuer
CHV&C Control = APPLICABLE, but has not provided the Cardholder
CHC Limit within the provisioning for the Digital Card, then the
Cardholder CHC Limit will be assumed to be greater than or equal to
the Issuer CHC Limit until the Cardholder CHC Limit is set to a value
less than the Issuer CHC Limit by the issuer or by the Mobile Payment
App.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder CHV Limit
15.03.2019 Page 127 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.13 Cardholder CHV Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Configuration Data and Device Configuration Data
Provision: Optional
Description: If present for the Digital Card and applicable according to Issuer CHV&C
Control, the Cardholder CHV Limit is the cardholder defined limit for the
transaction amount, below which cardholder verification is not required.
The currency code and the currency conversion table - if any - applicable
to this limit are defined in Issuer CHV&C Control.
The Cardholder CHV Limit is Device Configuration Data, i.e. it may be set
or updated by the Mobile Payment App.
The Cardholder CHV Limit is evaluated according to the following rules
(see Req C.30 and Req C.56):
'Cardholder CHV Limit' in Issuer CHV&C Control indicates, whether
Cardholder CHV Limit is to be used for the Digital Card.
If the issuer has chosen to not provide Issuer CHV&C Control or to set
'Cardholder CHV Limit' in Issuer CHV&C Control = NOT
APPLICABLE, then the value of Cardholder CHV Limit will have no
effect. Therefore the Mobile Payment App should not offer an option to
the cardholder to set or update this limit, if 'Cardholder CHV Limit' in
Issuer CHV&C Control = NOT APPLICABLE.
If the issuer has chosen to set 'Cardholder CHV Limit' in Issuer
CHV&C Control = APPLICABLE, then the value of Cardholder CHV
Limit will have no (additional) effect if its value is greater than or equal
to the Issuer CHV Limit. This should be taken into account when the
Mobile Payment App offers an option to the cardholder to set or
update this limit.
If the issuer has chosen to set 'Cardholder CHV Limit' in Issuer
CHV&C Control = APPLICABLE, but has not provided the Cardholder
CHV Limit within the provisioning for the Digital Card, then the
Cardholder CHV Limit will be assumed to be greater than or equal to
the Issuer CHV Limit until the Cardholder CHV Limit is set to a value
less than the Issuer CHV Limit by the issuer or by the Mobile Payment
App.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder CHV&C Control
15.03.2019 Page 128 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.14 Cardholder CHV&C Control
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Configuration Data and Device Configuration Data
Provision: Optional
Description: If present for the Digital Card and applicable according to Issuer CHV&C
Control, Cardholder CHV&C Control indicates whether the cardholder
wants to force a 2nd presentment for CDCVM cardholder verification and
cardholder confirmation for the Digital Card.
Cardholder CHV&C Control is coded as shown in Table 38.
Cardholder CHV&C Control is Device Configuration Data, i.e. it may be
set and updated by the Mobile Payment App.
Cardholder CHV&C Control is evaluated according to the following rules
(see Req C.62 and Req C.63):
'Cardholder Forced 2nd Presentment Setting' in Issuer CHV&C
Control indicates, whether Cardholder CHV&C Control is to be used
for the Digital Card.
If the issuer has chosen to not provide Issuer CHV&C Control or to set
'Cardholder Forced 2nd Presentment Setting' in Issuer CHV&C
Control = NOT APPLICABLE, then the value of Cardholder CHV&C
Control will have no effect. Therefore the Mobile Payment App should
not offer an option to the cardholder to set or update a requirement for
forcing a 2nd presentment, if 'Cardholder Forced 2nd Presentment
Setting' in Issuer CHV&C Control = NOT APPLICABLE.
If the issuer has chosen to set 'Cardholder Forced 2nd Presentment
Setting' in Issuer CHV&C Control = APPLICABLE, then the value of
Cardholder CHV&C Control will have no (additional) effect if it
indicates a weaker requirement for forcing a 2nd presentment than the
Issuer CHV&C Control. This should be taken into account when the
Mobile Payment App offers an option to the cardholder to set or
update this value.
If the issuer has chosen to set 'Cardholder Forced 2nd Presentment
Setting' in Issuer CHV&C Control = APPLICABLE, but has not
provided the Cardholder CHV&C Control within the provisioning for the
Digital Card, then the Cardholder CHV&C Control will be assumed to
indicate a weaker requirement for forcing a 2nd presentment than the
Issuer CHV&C Control until the Cardholder CHV&C Control is set to a
value indicating a stronger requirement than the Issuer CHV&C
Control by the issuer or by the Mobile Payment App.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Confirmation Data
15.03.2019 Page 129 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x - - - - RFU
- - - - x x - - Cardholder Forced 2nd Presentment Setting
- - - - 1 1 - - REQUIRED FOR CHV & CHC
- - - - 1 0 - - REQUIRED FOR CHV
- - - - 0 1 - - RFU
- - - - 0 0 - - NOT REQUIRED
- - - - - - x x RFU
Table 38: Cardholder CHV&C Control Coding
12.15 Cardholder Confirmation Data
Template: -
Tag: -
Length (in bytes): var. up to 9
Format: b
Category: Transaction Data
Description: Cardholder Confirmation Data is a transaction data element which may be
made available to CPACE-HCE EMV processing by the Mobile Payment
App together with Recent Cardholder Confirmation if a cardholder
confirmation with a CDCVM has occurred which requires verification by
the issuer.
If Cardholder Confirmation Data is provided by the Mobile Payment App
and if the cardholder confirmation is still valid ('Cardholder Confirmation
Performed' in the Card Verification Results (CVR) has the value 1b) and if
required by 'Include CHV or CHC Data in IAD' in the Issuer Options Profile
Control, then Cardholder Confirmation Data are included in the IDD part of
the Issuer Application Data (IAD) (see Req C.76 in Section 8.2.4.1).
The contents of Cardholder Confirmation Data is out of scope for CPACE-
HCE EMV processing.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Confirmation History
15.03.2019 Page 130 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.16 Cardholder Confirmation History
Template: -
Tag: -
Length (in bytes): 7
Format: n 14
Category: Dynamic Data
Provision: Not supported
Description: Cardholder Confirmation History is part of the structure Transaction
History. Cardholder Confirmation History is stored persistently to indicate
date and time of the last cardholder confirmation together with the number
of transactions for which this cardholder confirmation may still be used.
Cardholder Confirmation History coded as shown in Table 39.
When a Digital Card is provisioned, then Transaction History.Cardholder
Confirmation History shall be initialised with the fixed value '00..00'.
Position Data Length (in bytes)
Format Value
Bytes 1 - 6 Date and time of last
cardholder
confirmation
6 n 6 Date and time in the format
YYMMDDhhmmss
Byte 7 Number of remaining
transactions for this
cardholder
confirmation
1 n 2 Number of transactions for which
this cardholder confirmation may
still be used:
Cardholder Confirmation Usage
Limit - number of transactions for
which this cardholder confirmation
has been used
Table 39: Cardholder Confirmation History
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Confirmation Timeout
15.03.2019 Page 131 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.17 Cardholder Confirmation Timeout
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Conditional
Description: The Cardholder Confirmation Timeout indicates the time (in seconds)
defined by the issuer after which a cardholder confirmation is no longer
valid for the Digital Card.
Cardholder Confirmation Timeout shall be provided within the provisioning
of a Digital Card, if cardholder confirmation may occur, i.e. if both of the
following are true:
Issuer CHV&C Control is provided within the provisioning of the
Digital Card,
and either of the following is true:
'Issuer CHC Limit' in Issuer CHV&C Control = APPLICABLE,
or 'Cardholder CHC Limit' in Issuer CHV&C Control =
APPLICABLE.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Confirmation Usage Limit
15.03.2019 Page 132 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.18 Cardholder Confirmation Usage Limit
Template: -
Tag: -
Length (in bytes): 1
Format: n 2
Category: Configuration Data
Provision: Conditional
Description: The Cardholder Confirmation Usage Limit indicates the issuer defined
maximum number of transactions for which the same cardholder
confirmation may be used for a Digital Card.
Cardholder Confirmation Usage Limit shall be provided within the
provisioning of a Digital Card, if cardholder confirmation may occur, i.e. if
both of the following are true:
Issuer CHV&C Control is provided within the provisioning of the
Digital Card,
and either of the following is true:
'Issuer CHC Limit' in Issuer CHV&C Control = APPLICABLE,
or 'Cardholder CHC Limit' in Issuer CHV&C Control =
APPLICABLE.
Cardholder Confirmation Usage Limit must be provisioned with a value
greater than 0. Otherwise, cardholder confirmation will not be performed.
12.19 Cardholder Verification and Confirmation Status (CHV&CS)
Template: '77'
Tag: 'DF4B'
Length (in bytes): 3
Format: b
Category: Transaction Data
Description: This data element may be returned by CPACE-HCE EMV processing in
the first GENERATE AC response message data field to inform the kernel
about the status of cardholder verification and cardholder confirmation set
in the Digital Card that may influence the action flow of the merchant and
cardholder at the POS.
Cardholder Verification and Confirmation Status (CHV&CS) is coded as
shown in Table 40.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Verification and Confirmation Status (CHV&CS)
15.03.2019 Page 133 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x x x x Version Number
'00'
all other values RFU
2 x x x - - - - - RFU
- - - x - - - - Reserved
- - - - x - - - Context is conflicting
- - - - 0 - - - Context is not conflicting (no discrepancy is
detected in the data used for a first presentment
and the data used for a second presentment)
- - - - 1 - - - Context is conflicting (a discrepancy is detected
between the data used for a first presentment
and the data used for a second presentment, the
first and second presentment being both part of
the same transaction)
- - - - - x - - Not Used
- - - - - - x - Cardholder confirmation (ACK) required
- - - - - - 0 - ACK not required
- - - - - - 1 - ACK required
- - - - - - - x CDCVM cardholder verification required
- - - - - - - 0 CDCVM cardholder verification not required
- - - - - - - 1 CDCVM cardholder verification required
3 x x x x x x x x RFU
Table 40: Cardholder Verification and Confirmation Status (CHV&CS) Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 Cardholder Verification Data
15.03.2019 Page 134 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.20 Cardholder Verification Data
Template: -
Tag: -
Length (in bytes): var. up to 9
Format: b
Category: Transaction Data
Description: Cardholder Verification Data is a transaction data element which may be
made available to CPACE-HCE EMV processing by the Mobile Payment
App together with Recent CDCVM Cardholder Verification if a cardholder
verification with a CDCVM has occurred which requires verification by the
issuer.
If Cardholder Verification Data is provided by the Mobile Payment App
and if the cardholder verification is still valid ('CDCVM Performed' in the
Card Verification Results (CVR) has the value 1b) and if required by
'Include CHV or CHC Data in IAD' in the Issuer Options Profile Control,
then Cardholder Verification Data are included in the IDD part of the
Issuer Application Data (IAD) (see Req C.76 in Section 8.2.4.1).
The contents of Cardholder Verification Data is out of scope for this
specification.
12.21 Cardholder Verification Method (CVM) Results
Template: -
Tag: '9F34'
Length (in bytes): 3
Format: b
Category: Transaction Data received over the contactless interface
Description: Indicates the results of the last CVM performed. For details, see [EMV 4],
Annex A, Table 32.
CPACE for Host Card Emulation Data Dictionary Version 1.0 CDCVM Cardholder Verification History
15.03.2019 Page 135 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.22 CDCVM Cardholder Verification History
Template: -
Tag: -
Length (in bytes): 7
Format: n 14
Category: Dynamic Data
Provision: Not supported
Description: CDCVM Cardholder Verification History is part of the structure
Transaction History. CDCVM Cardholder Verification History is stored
persistently to indicate date and time of the last CDCVM cardholder
verification together with the number of transactions for which this
CDCVM cardholder verification may still be used.
CDCVM Cardholder Verification History coded as shown in Table 41.
When a Digital Card is provisioned, then Transaction History.CDCVM
Cardholder Verification History shall be initialised with the fixed value
'00..00'.
Position Data Length (in bytes)
Format Value
Bytes 1 - 6 Date and time of last
CDCVM cardholder
verification
6 n 6 Date and time in the format
YYMMDDhhmmss
Byte 7 Number of remaining
transactions for this
CDCVM cardholder
verification
1 n 2 Number of transactions for which
this CDCVM cardholder
verification may still be used: :
CDCVM Cardholder Verification
Usage Limit - number of
transactions for which this
CDCVM cardholder verification
has been used
Table 41: CDCVM Cardholder Verification History
CPACE for Host Card Emulation Data Dictionary Version 1.0 CDCVM Cardholder Verification Timeout
15.03.2019 Page 136 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.23 CDCVM Cardholder Verification Timeout
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Conditional
Description: The CDCVM Cardholder Verification Timeout indicates the time (in
seconds) defined by the issuer after which a cardholder verification is no
longer valid for the Digital Card.
CDCVM Cardholder Verification Timeout shall be provided within the
provisioning of a Digital Card, if CDCVM cardholder verification may
occur, i.e. if 'CDCVM Cardholder Verification Supported' (byte 1, bit b2) in
the Application Control has the value 1b (CDCVM Cardholder Verification
Supported).
12.24 CDCVM Cardholder Verification Usage Limit
Template: -
Tag: -
Length (in bytes): 1
Format: n 2
Category: Configuration Data
Provision: Conditional
Description: The CDCVM Cardholder Verification Usage Limit indicates the issuer
defined maximum number of transactions for which the same CDCVM
cardholder verification may be used for a Digital Card.
CDCVM Cardholder Verification Usage Limit shall be provided within the
provisioning of a Digital Card, if CDCVM cardholder verification may
occur, i.e. if 'CDCVM Cardholder Verification Supported' (byte 1, bit b2) in
the Application Control has the value 1b (CDCVM Cardholder Verification
Supported).
CDCVM Cardholder Verification Usage Limit must be provisioned with a
value greater than 0. Otherwise, CDCVM cardholder verification will not
be performed.
CPACE for Host Card Emulation Data Dictionary Version 1.0 CHC Limit
15.03.2019 Page 137 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.25 CHC Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Internal Working Variable
Description: CHC Limit is an internal parameter of CPACE-HCE EMV processing
which is used to store the minimum of CHV Limit, Issuer CHC Limit and
Cardholder CHC Limit.
12.26 CHV Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Internal Working Variable
Description: CHV Limit is an internal parameter of CPACE-HCE EMV processing
which is used to store the minimum of Issuer CHV Limit and Cardholder
CHV Limit.
12.27 CHV Required for Next Transaction
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data and Device Configuration Data
Provision: Optional
Description: CHV Required for Next Transaction is a flag indicating whether cardholder
verification shall be performed within the next transaction.
'01' CHV required for next transaction
'00' CHV not required for next transaction
All other values RFU.
CHV Required for Next Transaction is Device Configuration Data, i.e. it
may be set or updated by the Mobile Payment App.
If the issuer has not provided the CHV Required for Next Transaction
within the provisioning for the Digital Card, then CHV Required for Next
Transaction will be assumed to have the value '00' until it is set by the
issuer or by the Mobile Payment App.
CPACE for Host Card Emulation Data Dictionary Version 1.0 CHV Required for This Transaction
15.03.2019 Page 138 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.28 CHV Required for This Transaction
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Internal Working Variable
Description: CHV Required for This Transaction is a flag indicating whether cardholder
verification shall be performed within the current transaction.
'01' CHV required for current transaction
'00' CHV not required for current transaction
All other values RFU.
12.29 Cryptogram Information Data (CID)
Template: -
Tag: '9F27'
Length (in bytes): 1
Format: b
Description: Indicates the type of cryptogram and the actions to be performed by the
terminal. Returned by CPACE-HCE EMV processing in response to the
GENERATE AC command.
12.30 Default Issuer Application Data (IAD)
Template: -
Tag:
Length (in bytes): 32
Format: b
Category: Configuration Data
Provision: Optional
Description: The Issuer Application Data (IAD) informs the issuer about the application
during online transactions (in the authorisation request) and after
transaction completion in the clearing record. The Default Issuer
Application Data (IAD) send to the Digital Card within the personalisation
are used within a transaction as an initial value for each transaction.
If no value is provided for the data item during the provisioning of the
Digital Card, the default value 'FF..FF' shall be used (see Req C.75).
CPACE for Host Card Emulation Data Dictionary Version 1.0 Dynamic Issuer Data
15.03.2019 Page 139 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.31 Dynamic Issuer Data
Template: -
Tag: 'D1'
Length (in bytes): var.
Format: b
Category: Configuration Data and Device Configuration Data
Provision: Optional
Description: Contents and length of Dynamic Issuer Data are at the discretion of the
issuer.
If present for the Digital Card, the value of the Dynamic Issuer Data will be
included in the Issuer Discretionary Data (IDD) part of the Issuer
Application Data (IAD), if 'Include Dynamic Issuer Data in IAD' (byte 7, bit
b6) has the value 1b in the Issuer Options Profile Control and the IDD are
not already completely populated with other data (see Req C.76).
If Dynamic Issuer Data is not present for the Digital Card, the process
which populates the IDD skips inclusion of Dynamic Issuer Data in the
IDD (see Req C.76).
The Dynamic Issuer Data is Device Configuration Data. But it may only be
updated by the Mobile Payment App if a value is provided for the data
element during the provisioning of the Digital Card. In addition, the length
of the data element has to be preserved when it is updated by the Mobile
Payment App.
12.32 GPO Input Data
Template: -
Tag: -
Length (in bytes): var.
Format: b
Category: Internal Working Variable
Description: The value field of the data object PDOL Related Data. GPO Input Data is
a concatenation of data elements, the tags and lengths of which were sent
to the terminal in the PDOL.
CPACE for Host Card Emulation Data Dictionary Version 1.0 GPO Input Data Length
15.03.2019 Page 140 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.33 GPO Input Data Length
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Internal Working Variable
Description: The value expected by CPACE-HCE EMV processing for the length of the
GPO Input Data in the GET PROCESSING OPTIONS command in PDOL
Related Data.
This parameter is part of each GPO Parameters x data element in the
GPO Parameters template.
The value of the GPO Input Data Length must be consistent with the
contents personalised in the PDOL sent in the response to the SELECT
command.
12.34 GPO Parameters
Template: -
Tag: -
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Mandatory
Description: GPO Parameters is a numbered list of GPO Parameters x entries.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Application Data (IAD)
15.03.2019 Page 141 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.34.1 GPO Parameters x
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Mandatory
Description: GPO Parameters x contains the following parameters used during
processing of the GPO Command.
GPO Input Data Length (Byte 1)
The value expected by CPACE-HCE EMV processing for the
length of the GPO Input Data (the value field of the PDOL Related
Data).
Profile Selection Diversifier (Byte 2)
An identifier of card data associated with the Digital Card at the
time of Application Selection, used to support Profile Selection
based on card data.
The number x may have any value between 1 and 127.
At least one GPO Parameters x shall be provided within the provisioning
of a Digital Card.
12.35 Issuer Application Data (IAD)
Template: -
Tag: '9F10'
Length (in bytes): 32
Format: b
Description: The Issuer Application Data (IAD) informs the issuer about the application
during online transactions (in the authorisation request) and after
transaction completion in the clearing record. The coding of the data to be
sent in Issuer Application Data (IAD) is described in Table 15. The Default
Issuer Application Data (IAD) send to the Digital Card within the
personalisation are used within a transaction as an initial value for each
transaction.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Authentication Data (IATD)
15.03.2019 Page 142 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.36 Issuer Authentication Data (IATD)
Template: -
Tag: '91'
Length (in bytes): 8-16
Format: b
Category: Transaction Data received over the contactless interface
Description: Issuer Authentication Data (IATD) are sent from the issuer to CPACE-
HCE EMV processing for online Issuer Authentication.
The Issuer Authentication Data (IATD) expected by CPACE-HCE EMV
processing consists of the Data items listed in Table 42, in the order
shown.
Proprietary Authentication Data (PAD) shall be present in the Issuer
Authentication Data (IATD), i.e. Issuer Authentication Data (IATD) shall
have a length of 16 bytes, if and only if all of the following are true:
'Proprietary Authentication Data in IATD Supported' in the Issuer
Options Profile Control has the value 1b,
and 'Proprietary Authentication Data (PAD) Included' in Card
Status Update (CSU) has the value 1b,
and at least one of bits b8-b5 in byte 4 of Card Status Update
(CSU) has the value 1b.
Position Data Item Length
(in bytes)
Format Presence
Bytes 1 - 4 Authorisation Response Cryptogram (ARPC) 4 b M
Bytes 5 - 8 Card Status Update (CSU) 4 b M
Bytes 9 - 16 Proprietary Authentication Data (PAD) 8 b C
Table 42: Issuer Authentication Data (IATD)
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer CHC Limit
15.03.2019 Page 143 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.37 Issuer CHC Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Configuration Data
Provision: Optional
Description: If present for the Digital Card and applicable according to Issuer CHV&C
Control, the Issuer CHC Limit is the issuer defined limit for the transaction
amount, below which cardholder confirmation is not required.
The currency code and the currency conversion table - if any - applicable
to this limit are defined in Issuer CHV&C Control.
The Issuer CHC Limit is evaluated according to the following rules (see
Req C.63):
'Issuer CHC Limit' in Issuer CHV&C Control indicates, whether Issuer
CHC Limit is to be used for the Digital Card.
If the issuer has chosen to not provide Issuer CHV&C Control or to set
'Issuer CHC Limit' in Issuer CHV&C Control = NOT APPLICABLE,
then the value of Issuer CHC Limit will have no effect.
If the issuer has chosen to set 'Issuer CHC Limit' in Issuer CHV&C
Control = APPLICABLE, but has not provided the Issuer CHC Limit
within the provisioning for the Digital Card, then the default value
'00..00' will be used as Issuer CHC Limit until it is set to another value
by the issuer.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer CHV Limit
15.03.2019 Page 144 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.38 Issuer CHV Limit
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Configuration Data
Provision: Conditional
Description: If present for the Digital Card and applicable according to Issuer CHV&C
Control or to a Profile Selection Entry, the Issuer CHV Limit is the issuer
defined limit for the transaction amount, below which cardholder
verification is not required.
The currency code and the currency conversion table - if any - applicable
to this limit are defined in Issuer CHV&C Control.
Note:
The Issuer CHV Limit should not be greater than the CVM-Limit
defined by the respective scheme for the Digital Card. The Issuer CHV
Limit may be less than the CVM-Limit defined by the respective
scheme, thus requiring cardholder verification for lower transaction
amounts.
The Issuer CHV Limit shall be provided within the provisioning of a Digital
Card, if either of the following is true:
Check Type '40' is used in a Profile Selection Entry,
or both of the following are true:
Issuer CHV&C Control is provided within the provisioning of the
Digital Card,
and 'Issuer CHV Limit' in Issuer CHV&C Control =
APPLICABLE.
The Issuer CHV Limit is evaluated according to the following rules (see
Req C.30 and Req C.56):
Check Type '40' in a Profile Selection Entry or 'Issuer CHV Limit' in
Issuer CHV&C Control indicates, whether Issuer CHV Limit is to be
used for the Digital Card.
Note:
During Profile Selection (see Section 6.2.4), if Check Type '40' is
to be applied, the Issuer CHV Limit will be evaluated, without
evaluation of the value of 'Issuer CHV Limit' (bit b8) in the Issuer
CHV&C Control, since it may be assumed that Check Type '40' is
only used in a Profile Selection Entry, if 'Issuer CHV Limit' in
CHV&C Parameters = APPLICABLE.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer CHV Limit
15.03.2019 Page 145 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
If the issuer has chosen to not use Check Type '40' in a Profile
Selection Entry and either to not provide Issuer CHV&C Control or to
set 'Issuer CHV Limit' in Issuer CHV&C Control = NOT APPLICABLE,
then the value of Issuer CHV Limit will have no effect.
If the issuer has chosen to use Check Type '40' in a Profile Selection
Entry, but has not provided the Issuer CHV Limit within the
provisioning for the Digital Card, then the transaction will be
terminated when this Profile Selection Entry is processed.
If the issuer has chosen to set 'Issuer CHV Limit' in Issuer CHV&C
Control = APPLICABLE, but has not provided the Issuer CHV Limit
within the provisioning for the Digital Card, then the default value
'00..00' will be used as Issuer CHV Limit, but an error will be indicated
('Check Failed' (byte 3, bit b2) = 1b) in the Card Verification Results
(CVR) until the Issuer CHV Limit is set by the issuer.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer CHV&C Control
15.03.2019 Page 146 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.39 Issuer CHV&C Control
Template: -
Tag: -
Length (in bytes): 4
Format: b
Category: Configuration Data
Provision: Conditional
Description: If present for the Digital Card, Issuer CHV&C Control indicates issuer
options regarding
transaction amount limits for cardholder verification and cardholder
confirmation and
forcing a 2nd presentment for CDCVM cardholder verification and
cardholder confirmation.
defined for the Digital Card.
The respective limits are:
Cardholder CHC Limit
Cardholder CHV Limit
Issuer CHC Limit
Issuer CHV Limit
Issuer CHV&C Control is coded as shown in Table 43.
If the issuer has chosen to use Check Type '40' in a Profile Selection
Entry of a digital card, then Issuer CHV&C Control shall be provided within
the provisioning of the Digital Card.
If Check Type '40' is not used in any Profile Selection Entry of a digital
card, then it is the issuer's option to provide Issuer CHV&C Control within
the provisioning of the Digital Card.
For Check Type '40' in a Profile Selection Entry, Issuer CHV&C Control
will be evaluated according to the description of Req C.30.
If present for the Digital Card, Issuer CHV&C Control will be evaluated for
the CHV Limit exceeded check according to Req C.56, for the CDCVM
cardholder verification check according to Req C.62 and for the
cardholder confirmation check according to Req C.63.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer CHV&C Control
15.03.2019 Page 147 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Length (in bytes)
Format Value
Byte 1 CHV&C Parameters 1 b See Table 44
Note:
During Profile Selection (see
Section 6.2.4), if Check Type
'40' is to be applied, the Issuer
CHV Limit will be evaluated,
irrespective of whether 'Issuer
CHV Limit' in CHV&C
Parameters has the value
APPLICABLE or not
Bytes 2 - 3 CHV&C Currency
Code
2 n 3 Currency code for cardholder
verification and confirmation
limits, coded according to [ISO
4217]
Byte 4 CHV&C Currency
Conversion
1 b See Table 45
Table 43: Issuer CHV&C Control Coding
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x - - - - - - - Issuer CHV Limit
1 - - - - - - - APPLICABLE
0 - - - - - - - NOT APPLICABLE
- x - - - - - - Issuer CHC Limit
- 1 - - - - - - APPLICABLE
- 0 - - - - - - NOT APPLICABLE
- - x - - - - - Cardholder CHV Limit
- - 1 - - - - - APPLICABLE
- - 0 - - - - - NOT APPLICABLE
- - - x - - - - Cardholder CHC Limit
- - - 1 - - - - APPLICABLE
- - - 0 - - - - NOT APPLICABLE
- - - - x x - - Issuer Forced 2nd Presentment Setting
- - - - 1 1 - - REQUIRED FOR CHV & CHC
- - - - 1 0 - - REQUIRED FOR CHV
- - - - 0 1 - - RFU
- - - - 0 0 - - NOT REQUIRED
- - - - - - x - Cardholder Forced 2nd Presentment Setting
- - - - - - 1 - APPLICABLE
- - - - - - 0 - NOT APPLICABLE
- - - - - - - x RFU
Table 44: CHV&C Parameters Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Options Profile Control
15.03.2019 Page 148 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x x - - - - RFU
- - - - x x x x Currency Conversion Table ID
- - - - 1 1 1 1 Currency Conversion Not Allowed
Table 45: CHV&C Currency Conversion Coding
12.40 Issuer Options Profile Control
Template: -
Tag: -
Length (in bytes): 10
Format: b
Category: Internal Working Variable
Description: Issuer Options Profile Control is the Issuer Options Profile Control x used
in processing the transaction according to Req C.42 in Section 8.2.1 of
this document.
12.41 Issuer Options Profile Controls
Template: -
Tag: -
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Mandatory
Description: Issuer Options Profile Controls is a numbered list of up to 15 Issuer
Options Profile Control x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Options Profile Controls
15.03.2019 Page 149 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.41.1 Issuer Options Profile Control x
Template: -
Tag: -
Length (in bytes): 10
Format: b
Category: Configuration Data
Provision: Mandatory
Description: Issuer Options Profile Control x indicates the issuer options that control
application behaviour within all Profiles using this Issuer Options Profile
Control x.
The number x may have any integer value between 1 and 15.
At least one Issuer Options Profile Control x shall be provided within the
provisioning of a Digital Card.
Issuer Options Profile Control x is coded as shown in Table 46.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Options Profile Controls
15.03.2019 Page 150 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte Data Item Description
1 Issuer Options Profile
Parameters
See Table 47
2 First GENERATE AC
Command Data Length
Length of the command data to be sent in the first
GENERATE AC command message. The tags and
lengths of these data elements were sent to the
terminal in CDOL1.
The value of First GENERATE AC Command Data
Length must be consistent with the contents
personalised in CDOL1.
3 Second GENERATE AC
Command Data Length
Length of the command data to be sent in the second
GENERATE AC command message. The tags and
lengths of these data elements were sent to the
terminal in CDOL2.
The value of Second GENERATE AC Command
Data Length must be consistent with the contents
personalised in CDOL2.
4 Profile CCI Profile CCI indicates the value to be used for the
Common Core Identifier (CCI) in the Profile that
identifies the format of the Issuer Application Data
and the Cryptogram Version used to generate the
Application Cryptogram. Set to the value 'A5' or 'A6'
for CCD-compliant Profiles.
5 Profile DKI Profile DKI indicates the value to be used for the
Derivation Key Index (DKI) in the Profile that identifies
for an issuer the Issuer key used to derive the key
used to generate the Application Cryptogram.
6 RFU '00'
7 - 10 Proprietary Issuer Options
Profile Parameters
See Table 48
Table 46: Issuer Options Profile Control x Coding
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x x x - - - - - Not Used
- - - x - - - - Activate Maximum Number of Days Without CHV Check
- - - 0 - - - - Maximum Number of Days Without CHV Check Not Active
- - - 1 - - - - Maximum Number of Days Without CHV Check Active
- - - - x - - - Reset Last CHV Date in Days with Online Response (only applicable if IO1 is supported)
- - - - 0 - - - Do Not Reset Last CHV Date in Days with Online Response
- - - - 1 - - - Reset Last CHV Date in Days with Online Response
- - - - - x x x RFU/Not Used
Table 47: Issuer Options Profile Parameters
CPACE for Host Card Emulation Data Dictionary Version 1.0 Issuer Options Profile Controls
15.03.2019 Page 151 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x - - - - - - - Include No CHV End Date in IAD
0 - - - - - - - Do not Include No CHV End Date in IAD
1 - - - - - - - Include No CHV End Date in IAD
- x - - - - - - Include Static Issuer Data in IAD
- 0 - - - - - - Do not Include Static Issuer Data in IAD
- 1 - - - - - - Include Static Issuer Data in IAD
- - x - - - - - Include Dynamic Issuer Data in IAD
- - 0 - - - - - Do not Include Dynamic Issuer Data in IAD
- - 1 - - - - - Include Dynamic Issuer Data in IAD
- - - x - - - - Not Used
- - - - x - - - Proprietary Authentication Data in IATD Supported (only applicable if IO1 is supported)
- - - - 0 - - - Proprietary Authentication Data in IATD not Supported
- - - - 1 - - - Proprietary Authentication Data in IATD Supported
- - - - - x x x RFU/Not Used
2 x x x x - - - - RFU
- - - - x - - - Restart Supported (only applicable if IO1 is supported)
- - - - 0 - - - Restart not Supported
- - - - 1 - - - Restart Supported
- - - - - x - - Restart only if Supported by Terminal (only applicable if
IO1 is supported)7)
- - - - - 0 - - Restart irrespective of Supported by Terminal
- - - - - 1 - - Restart only if Supported by Terminal
- - - - - - x - Indicate Restart to Terminal (only applicable if IO1 is supported)
7)
- - - - - - 0 - Do not Indicate Restart to Terminal
- - - - - - 1 - Indicate Restart to Terminal
- - - - - - - x Update CHV Required for Next Transaction with CHV, Result Unknown
- - - - - - - 0 Do not Update CHV Required for Next Transaction with CHV, Result Unknown
- - - - - - - 1 Update CHV Required for Next Transaction with CHV, Result Unknown
3 x x - - - - - - RFU
- - x - - - - - Offline Decline Required
- - 0 - - - - - Offline Decline not Required
- - 1 - - - - - Offline Decline Required
- - - x - - - - Include CHV or CHC Data in IAD
- - - 0 - - - - Do not Include CHV or CHC Data in IAD
- - - 1 - - - - Include CHV or CHC Data in IAD
- - - - x - - - Update Last CHV Date in Days with Successful CHV
- - - - 0 - - - Do not Update Last CHV Date in Days with Successful CHV
- - - - 1 - - - Update Last CHV Date in Days with Successful CHV
- - - - - x - - Update Last CHV Date in Days with CHV, Result Unknown
7) This bit applies only if 'Restart Supported' bit is set to 1b.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Key Counter
15.03.2019 Page 152 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
- - - - - 0 - - Do not Update Last CHV Date in Days with CHV, Result Unknown
- - - - - 1 - - Update Last CHV Date in Days with CHV, Result Unknown
- - - - - - x x RFU
4 x x x x x x x x RFU
Table 48: Proprietary Issuer Options Profile Parameters
12.42 Key Counter
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data
Provision: Not supported
Description: Key Counter is generated and provided by a Digital Card's key database
and indicates the number of session keys still not used in the key
database. This number is used to trigger the replenishment of keys based
on the limits defined by the issuer (Key Counter Limits).
12.43 Key Counter Limits
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Mandatory
Description: The Key Counter Limits are defined by the issuer for key replenishment.
Key Counter Limits are coded as shown in Table 49. The usage of the
Key Counter Limits is described in Req C.116.
Data Item Length (in bytes)
Trigger Replenishment Limit 1 Byte
Force Replenishment Limit 1 Byte
Table 49: Key Counter Limits
CPACE for Host Card Emulation Data Dictionary Version 1.0 Key Validity Number of Days
15.03.2019 Page 153 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.44 Key Validity Number of Days
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Optional
Description: Support of Key Validity Number of Days is only required if IO4 is
supported.
If IO4 is supported, Key Validity Number of Days may be defined by the
issuer for key replenishment. Key Validity Number of Days are coded as
shown in Table 50. The usage of the Key Validity Number of Days is
described in Req C.116.
If the issuer has not provided the Key Validity Number of Days within the
provisioning for the Digital Card, then the default value '00 00' will be used
if IO4 is supported.
Data Item Length (in bytes)
Trigger Replenishment Number of Days 1 Byte
Force Replenishment Number of Days 1 Byte
Table 50: Key Validity Number of Days
CPACE for Host Card Emulation Data Dictionary Version 1.0 Last CHV Date in Days
15.03.2019 Page 154 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.45 Last CHV Date in Days
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Dynamic Data
Provision: Conditional
Description: Last CHV Date in Days is the date in days (see Annex 1) of the last
(successful) cardholder verification.
The Number of Days Without CHV, i.e. the difference between the current
transaction date and the Last CHV Date in Days is compared to the
Number of Days Without CHV Limit, triggering cardholder verification if
the limit is exceeded.
The Last CHV Date in Days and the Number of Days Without CHV Limit
are added and converted to a date in the format YYMMDD in order to
compute the No CHV End Date, if this is to be included in the Issuer
Application Data according to the setting of 'Include No CHV End Date in
IAD' (byte 7, bit b8) in the Issuer Options Profile Control.
The initial value of Last CHV Date in Days shall be provided within the
provisioning of a Digital Card, if the Maximum Number of Days Without
CHV Check is active for any profile, i.e. 'Activate Maximum Number of
Days Without CHV Check' (byte 1, bit b5) has the value 1b in any Issuer
Options Profile Control x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Accumulator
15.03.2019 Page 155 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.46 No CVM Accumulator
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Dynamic Data
Provision: Conditional
Description: No CVM Accumulator represents the cumulative amount of all
transactions without cardholder verification that were processed with
request for online authorisation since the last reset of No CVM
Accumulator. Transactions can be accumulated if they are in the
accumulator currency, i.e. if Transaction Currency Code = Accumulator
Currency Code.
The initial value of No CVM Accumulator shall be provided within the
provisioning of a Digital Card, if either of the following is true:
Check Type 'D3' is used in a Profile Selection Entry,
or the No CVM Accumulator is active for any profile, i.e. No CVM
Accumulator Profile Control ID has a value between '1' and 'E' in
any Profile Control x.
12.47 No CVM Accumulator Balance
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Transaction Data
Description: No CVM Accumulator Balance represents the amount still available for No
CVM Accumulator.
The No CVM Accumulator Balance is computed as follows:
No CVM Accumulator Balance = No CVM MaxAmount minus No CVM
Accumulator value.
If No CVM MaxAmount < No CVM Accumulator value, then No CVM
Accumulator Balance is set to zero ('00 00 00 00 00 00').
No CVM Accumulator Balance may be sent to the issuer as part of the
Issuer Application Data (IAD).
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Accumulator Control
15.03.2019 Page 156 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.48 No CVM Accumulator Control
Template: -
Tag: -
Length (in bytes): 4
Format: b
Category: Configuration Data
Provision: Conditional
Description: No CVM Accumulator Control defines the currency of the No CVM
Accumulator independently of a Profile.
No CVM Accumulator Control is coded as shown in Table 51.
No CVM Accumulator Control shall be provided within the provisioning of
a Digital Card, if the No CVM Accumulator is active for any profile, i.e. No
CVM Accumulator Profile Control ID has a value between '1' and 'E' in any
Profile Control x.
Position Data Length (in bytes)
Format Value
Bytes 1 - 2 Accumulator
Currency Code
2 n 3 Numeric Currency Code, in which
the accumulator is managed,
coded according to ISO 4217
Bytes 3 - 4 Accumulator
Parameters
2 b RFU/Not Used
Table 51: No CVM Accumulator Control
12.49 No CVM Accumulator Profile Control
Template: -
Tag: -
Length (in bytes): 10
Format: b
Category: Internal Working Variable
Description: No CVM Accumulator Profile Control is the No CVM Accumulator Profile
Control x used in processing the transaction according to Req C.49 in
Section 8.2.3.1 of this document.
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Accumulator Profile Controls
15.03.2019 Page 157 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.50 No CVM Accumulator Profile Controls
Template: -
Tag:
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Conditional
Description: No CVM Accumulator Profile Controls is a numbered list of up to 14 No
CVM Accumulator Profile Control x entries.
12.50.1 No CVM Accumulator Profile Control x
Template: -
Tag: -
Length (in bytes): 3
Format: b
Provision: Conditional
Description: No CVM Accumulator Profile Control x indicates the issuer's choice of
data and behaviour to configure the No CVM Accumulator within a Profile.
The number x may have any value between 1 and 14.
No CVM Accumulator Profile Control x is coded as shown in Table 52.
At least one No CVM Accumulator Profile Control x shall be provided
within the provisioning of a Digital Card, if the No CVM Accumulator is
active for any profile, i.e. No CVM Accumulator Profile Control ID has a
value between '1' and 'E' in any Profile Control x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Accumulator Profile Controls
15.03.2019 Page 158 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x - - - - - - - Not Used
- x - - - - - - Reset No CVM Accumulator with Online Response (only applicable if IO1 is supported)
- 0 - - - - - - Do not Reset No CVM Accumulator with Online Response
- 1 - - - - - - Reset No CVM Accumulator with Online Response
- - x - - - - - Send No CVM Accumulator in IAD
- - 0 - - - - - Do not Send No CVM Accumulator in IAD
- - 1 - - - - - Send No CVM Accumulator in IAD
- - - x - - - - Send No CVM Accumulator Balance
- - - 0 - - - - Send No CVM Accumulator Value
- - - 1 - - - - Send No CVM Accumulator Balance
- - - - x x x x RFU
2 x x x x - - - - RFU/Not Used
- - - - x x x x Currency Conversion Table ID
- - - - 1 1 1 1 Currency Conversion Not Allowed
3 x - - - - - - - Not Used
- x - - - - - - Reset No CVM Accumulator with Successful CHV
- 0 - - - - - - Do not Reset No CVM Accumulator with Successful CHV
- 1 - - - - - - Reset No CVM Accumulator with Successful CHV
- - x - - - - - Reset No CVM Accumulator with CHV, Result Unknown
- - 0 - - - - - Do not Reset No CVM Accumulator with CHV, Result Unknown
- - 1 - - - - - Reset No CVM Accumulator with CHV, Result Unknown
x x x x x RFU
Table 52: No CVM Accumulator Profile Control x Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Counter
15.03.2019 Page 159 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.51 No CVM Counter
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data
Provision: Conditional
Description: No CVM Counter counts the count of all contactless transactions without
cardholder verification that were processed with request for online
authorisation since the last reset.
The initial value of No CVM Counter shall be provided within the
provisioning of a Digital Card, if either of the following is true:
Check Type '93' is used in a Profile Selection Entry,
or the No CVM Counter is active for any profile, i.e. No CVM
Counter Profile Control ID has a value between '1' and 'E' in any
Profile Control x.
12.52 No CVM Counter Control
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Conditional
Description: No CVM Counter Control indicates the issuer's choice of data and
behaviour to configure No CVM Counter independently of a Profile.
No CVM Counter Control is coded as shown in Table 53.
No CVM Counter Control shall be provided within the provisioning of a
Digital Card, if the No CVM Counter is active for any profile, i.e. No CVM
Counter Profile Control ID has a value between '1' and 'E' in any Profile
Control x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Counter Profile Control
15.03.2019 Page 160 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x - - - - - Not Used
- - - x - - - - Include only if not Accumulated (Transaction is not Accumulated in the No CVM Accumulator)
- - - 0 - - - - include always
- - - 1 - - - - include only if not Accumulated
- - - - x - - - Not Used
- - - - x x x x RFU/Not Used
2 x - - - - - - - Not Used
- x x x - - - - RFU
- - - - x x x x Not Used
Table 53: No CVM Counter Control Coding
12.53 No CVM Counter Profile Control
Template: -
Tag: -
Length (in bytes): 10
Format: b
Category: Internal Working Variable
Description: No CVM Counter Profile Control is the No CVM Counter Profile Control x
used in processing the transaction according to Req C.50 in Section
8.2.3.1 of this document.
12.54 No CVM Counter Profile Controls
Template: -
Tag: -
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Conditional
Description: No CVM Counter Profile Controls is a numbered list of up to 14 No CVM
Counter Profile Control x entries.
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Counter Profile Controls
15.03.2019 Page 161 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.54.1 No CVM Counter Profile Control x
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Conditional
Description: No CVM Counter Profile Control x indicates the issuer's choice of data
and behaviour to configure No CVM Counter within a Profile.
The number x may have any value between 1 and 14.
No CVM Counter Profile Control x is coded as shown in Table 54.
At least one No CVM Counter Profile Control x shall be provided within
the provisioning of a Digital Card, if the No CVM Counter is active for any
profile, i.e. No CVM Counter Profile Control ID has a value between '1'
and 'E' in any Profile Control x.
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x x - - - RFU/Not Used
- - - - - x - - Reset No CVM Counter with Online Response (only applicable if IO1 is supported)
- - - - - 0 - - Do not Reset No CVM Counter with Online Response
- - - - - 1 - - Reset No CVM Counter with Online Response
- - - - - - x - Send No CVM Counter in IAD
- - - - - - 0 - Do not Send No CVM Counter in IAD
- - - - - - 1 - Send No CVM Counter in IAD
- - - - - - - x RFU
2 x - - - - - - - Not Used
- x - - - - - - Reset No CVM Counter with Successful CHV
- 0 - - - - - - Do not Reset No CVM Counter with Successful CHV
- 1 - - - - - - Reset No CVM Counter with Successful CHV
- - x - - - - - Reset No CVM Counter with CHV, Result Unknown
- - 0 - - - - - Do not Reset No CVM Counter CHV, Result Unknown
- - 1 - - - - - Reset No CVM Counter with CHV, Result Unknown
x x x x x RFU
Table 54: No CVM Counter Profile Control x Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM MaxAmount
15.03.2019 Page 162 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.55 No CVM MaxAmount
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Provision: Conditional
Category: Configuration Data
Description: No CVM MaxAmount represents the limit used to compare with the No
CVM Accumulator.
No CVM MaxAmount shall be provided within the provisioning of a Digital
Card, if either of the following is true:
Check Type 'D3' is used in a Profile Selection Entry,
or the No CVM Accumulator is active for any profile, i.e. No CVM
Accumulator Profile Control ID has a value between '1' and 'E' in
any Profile Control x.
12.56 No CVM MaxNumber
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Configuration Data
Provision: Conditional
Description: No CVM MaxNumber represents the limit used to compare with the No
CVM Counter.
No CVM MaxNumber shall be provided within the provisioning of a Digital
Card, if either of the following is true:
Check Type '93' is used in a Profile Selection Entry,
or the No CVM Counter is active for any profile, i.e. No CVM
Counter Profile Control ID has a value between '1' and 'E' in any
Profile Control x.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Number of Days Without CHV Limit
15.03.2019 Page 163 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.57 Number of Days Without CHV Limit
Template: -
Tag: -
Length (in bytes): 2
Format: n 4
Category: Configuration Data
Provision: Conditional
Description: The Number of Days Without CHV Limit is the limit associated with the
number of days since cardholder verification has (successfully) be
performed. The Number of Days Without CHV is measured from the date
of the previous (successful) cardholder verification.
The Number of Days Without CHV, i.e. the difference between the current
transaction date and the Last CHV Date in Days is compared to the
Number of Days Without CHV Limit, triggering cardholder verification if
the limit is exceeded.
The Last CHV Date in Days and the Number of Days Without CHV Limit
are added and converted to a date in the format YYMMDD in order to
compute the No CHV End Date, if this is to be included in the Issuer
Application Data according to the setting of the "Include No CHV End
Date in IAD" bit (byte 7, bit b8) in the Issuer Options Profile Control.
Number of Days Without CHV Limit shall be provided within the
provisioning of a Digital Card, if the Maximum Number of Days Without
CHV Check is active for any profile, i.e. 'Activate Maximum Number of
Days Without CHV Check' (byte 1, bit b5) has the value 1b in any Issuer
Options Profile Control x.
12.58 Online Parameter
Template: '77'
Tag: '9F55'
Length (in bytes): 1
Format: b
Category: Transaction Data
Description: If IO1 is supported, the Online Parameter may be returned in the first
GENERATE AC response to indicate that the Digital Card is prepared to
restart for Issuer Update Processing.
The Online Parameter is coded as shown in Table 55.
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 - - - - - - - Restart Expected
- x x x x x x x RFU
CPACE for Host Card Emulation Data Dictionary Version 1.0 PDOL Related Data
15.03.2019 Page 164 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Table 55: Online Parameter Coding
12.59 PDOL Related Data
Template: -
Tag: '83'
Length (in bytes): var.
Format: b
Category: Transaction Data
Description: The data object sent in the GET PROCESSING OPTIONS command.
PDOL Related Data begins with tag '83' and the length field, so the
minimum length for PDOL Related Data is 2 bytes. The value field of the
data object, if present, is the GPO Input Data.
12.60 Previous Transaction History (PTH)
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Dynamic Data
Provision: Not supported
Description: Support of Previous Transaction History (PTH) is only required if IO1 is
supported.
Previous Transaction History (PTH) is used to store persistently
information about the previous transactions.
When a Digital Card is provisioned and IO1 is supported, then this data
element shall be initialised with the fixed value '00 00'.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Control
15.03.2019 Page 165 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x - - - - - - Not Used
- - x - - - - - RFU
- - - x x - - - Not Used
- - - - - x - - Issuer Authentication Failed
- - - - - 0 - - Issuer Authentication did not Fail
- - - - - 1 - - Issuer Authentication Failed (that is, was performed and did not pass)
- - - - - - x x Not Used
2 x - - - - - - - Issuer Authentication Data Not Received in Online Response
0 - - - - - - - Issuer Authentication Data Received in Online Response
1 - - - - - - - Issuer Authentication Data Not Received in Online Response
- x - - - - - - Not Used
- - x x x x x x RFU
Table 56: Previous Transaction History (PTH)
12.61 Profile Control
Template: -
Tag: -
Length (in bytes): 10
Format: b
Category: Internal Working Variable
Description: Profile Control is the Profile Control x used in processing the transaction
according to Req C.31 in Section 6.2.5 of this document.
12.62 Profile Control Table
Template: -
Tag: -
Length (in bytes): not applicable
Format: Numbered List
Category: Configuration Data
Provision: Mandatory
Description: Profile Control Table is a numbered list of Profile Control x entries.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Control Table
15.03.2019 Page 166 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.62.1 Profile Control x
Template: -
Tag: -
Length (in bytes): 8
Format: b
Provision: Mandatory
Description: Profile Control x is a list of resource IDs and resource control IDs that
identify the Profile-specific data and behaviour when processing a
transaction using Profile ID x.
The number x may have any value between 1 and 126.
At least one Profile Control x shall be provided within the provisioning of a
Digital Card.
Every Profile Control x of the Digital Card shall have a length of 8 bytes.
Profile Control x is coded as shown in Table 57.
Issuer Options Profile Control ID and AIP/AFL ID in byte 1 of a Profile
Control x shall have a value between '1' and 'E'.
No CVM Accumulator Profile Control ID and No CVM Counter Profile
Control ID shall have a value between '1' and 'F'.
No CVM Accumulator Profile Control ID = 'F' indicates that the No CVM
Accumulator shall not be active for the respective profile.
No CVM Counter Profile Control ID = 'F' indicates that the No CVM
Counter shall not be active for the respective profile.
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x x x x - - - - Issuer Options Profile Control ID
- - - - x x x x AIP/AFL ID
2 x x x x - - - - Not Used
- - - - x x x x No CVM Accumulator Profile Control ID
3 x x x x - - - - Not Used
- - - - x x x x No CVM Counter Profile Control ID
4 x x x x x x x x Not Used
5 x x x x x x x x Not Used
6 x x x x x x x x Not Used
7 x x x x x x x x RFU
8 x x x x x x x x RFU
Table 57: Profile Control x Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile ID
15.03.2019 Page 167 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.63 Profile ID
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Internal Working Variable
Description: Identifies the Profile to be used in processing the transaction. The Profile
ID is the output of the Profile Selection algorithm, and has a value in the
range '01' to '7F'.
The value '7F' is reserved to indicate that the GET PROCESSING
OPTIONS command is to be rejected by CPACE-HCE EMV processing.
The values '70' to '7E' are RFU for EMVCo.
The following Profile IDs are pre-assigned in this specification:
Default Profile ('01')
Reject GPO Command ('7F')
12.64 Profile Selection Table
Template: -
Tag: -
Length (in bytes): not applicable.
Format: List
Category: Configuration Data
Provision: Conditional
Description: The Profile Selection Table is an internal list with all Profile Selection
Entries assigned to a Digital Card.
12.64.1 Profile Selection Entry
Template: -
Tag: -
Length (in bytes): var.
Format: b
Provision: Conditional
Description: The coding of a Profile Selection Entry is shown in Table 58, Table 59 and
Table 60.
At least one Profile Selection Entry shall be provided within the
provisioning of a Digital Card, if 'Activate Profile Selection Table' in
Application Control = 1b.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Selection Table
15.03.2019 Page 168 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Item Length (in bytes)
Format Description
Byte 1 Entry Length 1 b Profile Selection Entry length (not
including the Entry Length)
Byte 2 Position P in
Extended GPO
Input Data
1 b A value greater than '00' indicates the
position of the first byte of data extracted
from the Extended GPO Input Data that
is compared to the comparison values
listed in this Profile Selection Entry.
If the first byte in the first Extended GPO
Input Data is extracted for comparison,
the value of P is '01'.
The value '00' indicates that no data shall
be extracted from the Extended GPO
Input Data.
The value '00' is not allowed for Check
Types '00', '01', '02', 'D3', '40'. It is only
allowed for Check Type '41' and '93'.
Byte 3 Length L of
Extraction Block
and/or
Comparison
Block
1 b If data is to be extracted from the
Extended GPO Input Data (the value of P
in byte 2 is greater than '00') the value of
byte 3 shall be greater than '00' and
indicates the length L in bytes of the data
to be extracted from the Extended GPO
Input Data. If comparison blocks are to
be used (the value of byte 4 is greater
than '00') the value of byte 3 shall be
greater than '00' and indicates the length
L in bytes of the comparison value(s).
If byte 2 and byte 4 of the Profile
Selection Entry have the value '00' the
value of byte 3 is not evaluated and
should be set to '00'
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Selection Table
15.03.2019 Page 169 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Item Length (in bytes)
Format Description
Byte 4 Number n of
Comparison
Blocks
1 b The number n of comparison blocks in
this Profile Selection Entry.
A value greater than or equal to '02'
indicates that the first comparison block
is a bit mask and that the second and
subsequent comparison block(s) are
comparison values that are compared to
the data extracted from Extended GPO
Input Data.
The value '00' indicates that no
comparison blocks are used.
The value '00' is not allowed for Check
Types '00', '01', '02'. The value '00' is
used for Check Types '40', '41', 'D3' and
'93'.
Bytes 5 - 4+n*L Comparison
Blocks
var. b Comparison Blocks are only present if n
(and therefore also L) is greater than 0.
For the coding of Comparison Blocks,
see Table 59
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Selection Table
15.03.2019 Page 170 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Item Length (in bytes)
Format Description
Byte n*L+5 Check Type 1 b Identifies the type of test to be performed
using the masked data extracted from the
Extended GPO Input Data and the
comparison value(s).
The Check Type is identified as follows:
Match (Check Type = '00')
Tests whether the masked value
extracted from the Extended GPO
Input Data is equal to any of the
comparison values in this Profile
Selection Entry.
Less Than (Check Type = '01')
Tests whether the masked value
extracted from the Extended GPO
Input Data is less than comparison
value 1 in this Profile Selection Entry.
Greater Than (Check Type = '02')
Tests whether the masked value
extracted from the Extended GPO
Input Data is greater than
comparison value 1 in this Profile
Selection Entry.
No CVM MaxAmount exceeded (Check
Type = 'D3')
Test whether No CVM Accumulator +
Transaction Amount is greater than
No CVM MaxAmount.
No CVM MaxNumber exceeded (Check
Type = '93')
Tests whether No CVM Counter + 1
is greater than No CVM MaxNumber.
CHV Limit exceeded (Check Type =
'40')
Tests whether Transaction Amount is
greater than Issuer CHV Limit or, if
applicable, Cardholder CHV Limit.
CHV Required for Next Transaction
(Check Type = '41')
Tests whether CHV Required for
Next Transaction is set.
Byte n*L+6 Positive Action 1 b Action to be taken when the Check Type
test is true.
See Table 60
CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile Selection Table
15.03.2019 Page 171 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Position Data Item Length (in bytes)
Format Description
Byte n*L+7 Negative Action 1 b Action to take when the Check Type test
is false.
See Table 60
Table 58: Profile Selection Entry Coding
Position Data Item Length (in bytes)
Format Description
Bytes 1 - L Bit Mask L b Used to mask the data extracted from
the Extended GPO Input Data, allowing
the comparison to be based on a portion
of the extracted data.
Set to 0b for each bit that is not used in
the comparison, and set to 1b for each
bit that is used in the comparison.
Bytes L+1
- 2*L
Comparison
Value 1
L b The first value compared to the masked
data extracted from the Extended GPO
Input Data.
… … … … …
Bytes (n-1)*L+1
- n*L
Comparison
Value n-1
L b The last value compared to the masked
data extracted from the Extended GPO
Input Data.
Table 59: Comparison Blocks Coding
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
x - - - - - - - Meaning of bits b7 - b1
0 - - - - - - - Select Profile ID
1 - - - - - - - Move down in Profile Selection
- x x x x x x x Profile ID (b8 = 0) or Number of Profile Selection Entries to move down in the Profile Selection Table for the next Profile Selection Entry to process (b8 = 1)
Table 60: Positive and Negative Action Byte Coding
CPACE for Host Card Emulation Data Dictionary Version 1.0 Proprietary Authentication Data (PAD)
15.03.2019 Page 172 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.65 Proprietary Authentication Data (PAD)
Template: -
Tag: -
Length (in bytes): 8
Format: b
Category: Transaction Data
Description: Proprietary Authentication Data (PAD) may be sent from the issuer to the
Digital Card in bytes 9-16 of Issuer Authentication Data (IATD) (see
Section 12.36).
Proprietary Authentication Data (PAD) are defined by this specification.
Proprietary Authentication Data (PAD) are coded as shown in Table 61.
Position Data Item Length
(in bytes)
Format
Bytes 1-2 New Number of Days Without CHV Limit 2 n 4
or filler
Bytes 3 - 8 New No CVM MaxAmount 6 n 12
or filler8) b
Table 61: Proprietary Authentication Data (PAD) Coding
12.66 Recent Cardholder Confirmation
Template: -
Tag: -
Length (in bytes): -
Format: -
Category: Transaction Data
Description: Recent Cardholder Confirmation is a transaction data element which is
made available to CPACE-HCE EMV processing by the Mobile Payment
App.
Recent Cardholder Confirmation indicates whether a cardholder
confirmation has occurred and, if a cardholder confirmation has occurred,
date and time in seconds of the most recent cardholder confirmation.
It is out of scope for CPACE-HCE EMV processing in which way a
cardholder confirmation is performed.
8) Filler bytes contained in the PAD may have any value or format. Therefore, filler bytes are considered to have the
format b (binary).
CPACE for Host Card Emulation Data Dictionary Version 1.0 Recent CDCVM Cardholder Verification
15.03.2019 Page 173 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.67 Recent CDCVM Cardholder Verification
Template: -
Tag: -
Length (in bytes): -
Format: -
Category: Transaction Data
Description: Recent CDCVM Cardholder Verification is a transaction data element
which is made available to CPACE-HCE EMV processing by the Mobile
Payment App.
Recent CDCVM Cardholder Verification indicates whether a CDCVM
cardholder verification has occurred and, if a CDCVM cardholder
verification has occurred,
date and time in seconds of the most recent CDCVM cardholder
verification and
if the CDCVM cardholder verification was successful or if the result
is unknown.
It is out of scope for CPACE-HCE EMV processing in which way a
CDCVM cardholder verification is performed.
12.68 Restart Flag
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Internal Working Variable
Description: The Restart Flag is an internal flag stored transiently to indicate, whether
a second GENERATE AC command is processed after a restart or
without a restart.
'00' No Restart
'01' Restart
All other values RFU
CPACE for Host Card Emulation Data Dictionary Version 1.0 Restart Indicator
15.03.2019 Page 174 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.69 Restart Indicator
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data
Provision: Not supported
Description: The Restart Indicator is part of the structure Transaction History. The
Restart Indicator is stored persistently to indicate whether a second
GENERATE AC command is allowed for the Digital Card immediately
after its next selection.
'00' No Restart
'01' Restart allowed
All other values are RFU.
When a Digital Card is provisioned, then Transaction History.Restart
Indicator shall be initialised with the fixed value '00'.
12.70 Second Presentment Indicator
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data
Provision: Not supported
Description: The Second Presentment Indicator is part of the structure Transaction
History. The Second Presentment Indicator is stored persistently to
indicate whether CDCVM cardholder verification or cardholder
confirmation and a subsequent second presentment of the Digital Card
are required. The Second Presentment Indicator is set to one of the
following values by first GENERATE AC processing:
'00' No second presentment required
'01' Second presentment required
'02' Second presentment failed
All other values are RFU.
When a Digital Card is provisioned, then Transaction History.Second
Presentment Indicator shall be initialised with the fixed value '00'.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Second Presentment Timeout
15.03.2019 Page 175 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.71 Second Presentment Timeout
Template: -
Tag: -
Length (in bytes): 2
Format: b
Category: Configuration Data
Provision: Conditional
Description: The Second Presentment Timeout indicates the time (in seconds) defined
by the issuer after which a contactless transaction is no longer considered
a second presentment for a Digital Card.
Second Presentment Timeout shall be provided within the provisioning of
a Digital Card, if CDCVM cardholder verification or cardholder
confirmation may occur, i.e. if either of the following is true:
'CDCVM Cardholder Verification Supported' (byte 1, bit b2) in the
Application Control has the value 1b (CDCVM Cardholder
Verification Supported),
or both of the following are true:
Issuer CHV&C Control is provided within the provisioning of the
Digital Card,
and either of the following is true:
'Issuer CHC Limit' in Issuer CHV&C Control =
APPLICABLE,
or 'Cardholder CHC Limit' in Issuer CHV&C Control =
APPLICABLE.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Static Issuer Data
15.03.2019 Page 176 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.72 Static Issuer Data
Template: -
Tag: 'D0'
Length (in bytes): var.
Format: b
Category: Configuration Data
Provision: Optional
Description: Contents and length of Static Issuer Data are at the discretion of the
issuer.
If present for the Digital Card, the (first bytes of the) value of the Static
Issuer Data will be included in the Issuer Discretionary Data (IDD) part of
the Issuer Application Data (IAD), if 'Include Static Issuer Data in IAD'
(byte 7, bit b7) has the value 1b in the Issuer Options Profile Control (see
Req C.76).
If Static Issuer Data is not present for the Digital Card, the process which
populates the IDD skips inclusion of Static Issuer Data in the IDD (see
Req C.76).
12.73 Terminal Country Code
Template: -
Tag: '9F1A'
Length (in bytes): 2
Format: n 3
Category: Transaction Data
Description: Indicates the country of the terminal, represented according to [ISO 3166-
1].
12.74 Terminal Risk Management Data
Template: -
Tag: '9F1D'
Length (in bytes): 8
Format: b
Category: Transaction Data
Description: Terminal Risk Management Data is an EMV terminal data object the
format of which is application specific.
For usage with CPACE-HCE EMV processing it is coded as shown in
Table 62.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Terminal Risk Management Data
15.03.2019 Page 177 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
1 x - - - - - - - Restart supported
0 - - - - - - - Restart not supported
1 - - - - - - - Restart supported
- x - - - - - - Enciphered PIN verified online (Contactless)
- 0 - - - - - - Enciphered PIN not verified online (Contactless)
- 1 - - - - - - Enciphered PIN verified online (Contactless)
- - x - - - - - Signature (paper) (Contactless)
- - 0 - - - - - No Signature (paper) (Contactless)
- - 1 - - - - - Signature (paper) (Contactless)
- - - x - - - - Enciphered PIN verification performed by ICC
(Contactless)
- - - 0 - - - - Enciphered PIN verification not performed by
ICC (Contactless)
- - - 1 - - - - Enciphered PIN verification performed by ICC
(Contactless)
- - - - x - - - No CVM required (Contactless)
- - - - 0 - - - No CVM not required (Contactless)
- - - - 1 - - - No CVM required (Contactless)
- - - - - x - - On device cardholder verification (Contactless)
- - - - - 0 - - No On device cardholder verification
(Contactless)
- - - - - 1 - - On device cardholder verification (Contactless)
- - - - - - x - Plaintext PIN verification performed by ICC
(Contactless)
- - - - - - 0 - Plaintext PIN verification not performed by ICC
(Contactless)
- - - - - - 1 - Plaintext PIN verification performed by ICC
(Contactless)
- - - - - - - x Present and Hold supported
- - - - - - - 0 Present and Hold not supported
- - - - - - - 1 Present and Hold supported
CPACE for Host Card Emulation Data Dictionary Version 1.0 Terminal Risk Management Data
15.03.2019 Page 178 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
2 x - - - - - - - RFU
- x - - - - - - Enciphered PIN verified online (Contact)
- 0 - - - - - - Enciphered PIN verified online (Contact)
- 1 - - - - - - Enciphered PIN verified online (Contact)
- - x - - - - - Signature (paper) (Contact)
- - 0 - - - - - No Signature (paper) (Contact)
- - 1 - - - - - Signature (paper) (Contact)
- - - x - - - - Enciphered PIN verification performed by ICC
(Contact)
- - - 0 - - - - Enciphered PIN verification not performed by
ICC (Contact)
- - - 1 - - - - Enciphered PIN verification performed by ICC
(Contact)
- - - - x - - - No CVM required (Contact)
- - - - 0 - - - No CVM not required (Contact)
- - - - 1 - - - No CVM required (Contact)
- - - - - x - - On device cardholder verification (Contact)
- - - - - 0 - - No On device cardholder verification (Contact)
- - - - - 1 - - On device cardholder verification (Contact)
- - - - - - x - Plaintext PIN verification performed by ICC
(Contact)
- - - - - - 0 - Plaintext PIN verification not performed by ICC
(Contact)
- - - - - - 1 - Plaintext PIN verification performed by ICC
(Contact)
- - - - - - - x RFU
3 x - - - - - - - Mag-Stripe-Mode contactless transactions not
supported
0 - - - - - - - Mag-Stripe-Mode contactless transactions
supported
1 - - - - - - - Mag-Stripe-Mode contactless transactions not
supported
- x - - - - - - EMV-Mode contactless transactions not
supported
- 0 - - - - - - EMV-Mode contactless transactions supported
- 1 - - - - - - EMV-Mode contactless transactions not
supported
- - x x x x x x RFU
CPACE for Host Card Emulation Data Dictionary Version 1.0 Terminal Type
15.03.2019 Page 179 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Byte b8 b7 b6 b5 b4 b3 b2 b1 Meaning
4 x x x x x x x x RFU
5 x x x x x x x x RFU
6 x x x x x x x x RFU
7 x x x x x x x x RFU
8 x x x x x x x x RFU
Table 62: Terminal Risk Management Data
12.75 Terminal Type
Template: -
Tag: '9F35'
Length (in bytes): 1
Format: n 2
Description: Indicates the environment of the terminal, its communications capability,
and its operational control. For details, see [EMV 4], Annex A, Table 23.
12.76 Terminal Verification Results (TVR)
Template: -
Tag: '95'
Length (in bytes): 5
Format: b
Description: Status of the different functions as seen from the terminal. For details, see
[EMV 3], Annex C, Table 42.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Time of First Presentment
15.03.2019 Page 180 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.77 Time of First Presentment
Template: -
Tag: -
Length (in bytes): -
Format: -
Category: Dynamic Data
Description: Time of First Presentment is part of the structure Transaction History. If
the Second Presentment Indicator is set to "Second presentment
required" by first GENERATE AC processing, then date and time in
seconds of the first presentment, i.e. date and time of storing Transaction
History, are stored in Time of First Presentment by first GENERATE AC
processing.
Note:
Transaction History.Time of First Presentment is evaluated using
Second Presentment Timeout during first GENERATE AC processing
when checking for first or second presentment, if Transaction
History.Second Presentment Indicator indicates "Second presentment
required" (see Req C.52).
Alternatively, Transaction History.Time of First Presentment may be
stored when first GENERATE AC processing is finalised, the time
elapsed since this time is observed and Transaction History.Second
Presentment Indicator is set to "No second presentment required"
when Second Presentment Timeout occurs.
12.78 Transaction Amount
Template: -
Tag: -
Length (in bytes): 6
Format: n 12
Category: Internal Working Variable
Description: Transaction Amount is an internal parameter of CPACE-HCE EMV
processing which is used during GET PROCESSING OPTIONS
command processing to store the 6-byte part of the command data field
containing the transaction amount.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Transaction Currency Code
15.03.2019 Page 181 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.79 Transaction Currency Code
Template: -
Tag: '5F2A'
Length (in bytes): 2
Format: n 3
Category: Transaction Data
Description: Transaction Currency Code indicates the currency code of the transaction
according to [ISO 4217].
12.80 Transaction CVM
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Internal Working Variable
Description: Transaction CVM is an internal parameter of CPACE-HCE EMV
processing which is used to store the CVM with which cardholder
verification was performed.
'01' CDCVM, successful
'11' CDCVM, result unknown
'02' Online PIN (selected for cardholder verification, result unknown)
'00' No CVM (none of the above)
All other values RFU.
Note:
According to this definition, Transaction CVM has the value No CVM,
if cardholder verification was not performed or failed, or if cardholder
verification was performed using No CVM Required as CVM.
12.81 Transaction Date
Template: -
Tag: '9A'
Length (in bytes): 3
Format: n 6 (YYMMDD)
Category: Transaction Data
Description: Local date that the transaction was authorised.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Transaction History
15.03.2019 Page 182 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.82 Transaction History
Template: -
Tag: -
Length (in bytes): not applicable
Format: Structure
Category: Dynamic Data
Provision: Not supported
Description: Transaction History is a structure consisting of the following data
elements:
Amount, Authorised
Amount, Other
Transaction Currency Code
Transaction Date
Transaction Type
Cardholder Verification Method (CVM) Results
Terminal Verification Results (TVR)
Card Verification Results (CVR)
Application Transaction Counter (ATC)
Cryptogram Information Data (CID)
Application Cryptogram
Cardholder Verification and Confirmation Status (CHV&CS)
Profile ID
AID Selected
Second Presentment Indicator
Time of First Presentment (if Second Presentment Indicator
indicates "Second presentment required")
Restart Indicator ('00', if IO1 is not supported)
Terminal Country Code
CDCVM Cardholder Verification History
Cardholder Confirmation History
Transaction History is used to store information on the current transaction
persistently. Transaction History will be evaluated when the Digital Card is
selected the next time.
CPACE for Host Card Emulation Data Dictionary Version 1.0 Transaction Type
15.03.2019 Page 183 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
When a Digital Card is provisioned, then
Transaction History.Second Presentment Indicator shall be
initialised with the fixed value '00',
Transaction History.Restart Indicator shall be initialised with the
fixed value '00',
Transaction History.CDCVM Cardholder Verification History shall
be initialised with the fixed value '00..00',
Transaction History.Cardholder Confirmation History shall be
initialised with the fixed value '00..00',
all other data elements constituting Transaction History may be
initialised with an arbitrary value.
Note:
According to the description of first GENERATE AC processing, if IO1
is supported, then Restart Indicator and Second Presentment Indicator
will never indicate at the same time that a restart (for 2nd GENERATE
AC) is allowed and that a second presentment (after cardholder
confirmation) is required.
12.83 Transaction Type
Template: -
Tag: '9C'
Length (in bytes): 1
Format: n 2
Category: Transaction Data
Description: Indicates the type of financial transaction, represented by the first two
digits of Processing Code defined in [ISO 8583:1987]. The actual values
to be used are defined by the relevant payment systems.
12.84 Unpredictable Number
Template: -
Tag: '9F37'
Length (in bytes): 4
Format: b
Category: Transaction Data
Description: Value to provide variability and uniqueness to the generation of a
cryptogram.
CPACE for Host Card Emulation Data Dictionary Version 1.0 UI Module Data
15.03.2019 Page 184 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.85 UI Module Data
Template: -
Tag: -
Length (in bytes): not applicable.
Format: Numbered List
Category: Configuration Data
Provision: Optional
Description: Up to 16 UI Module Data Entry x may be stored in the UI Module Data for
each Digital Card for retrieval by the Mobile Payment App.
12.85.1 UI Module Data Entry x
Template: -
Tag: -
Length (in bytes): var. up to 252
Format: b
Provision: Optional
Description: Meaning, length and format of these data elements are determined by the
issuer.
The number x may have any value between 1 and 16.
CPACE for Host Card Emulation Data Dictionary Version 1.0 x Days Valid Key Counter
15.03.2019 Page 185 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
12.86 x Days Valid Key Counter
Template: -
Tag: -
Length (in bytes): 1
Format: b
Category: Dynamic Data
Provision: Not supported
Description: Support of x Days Valid Key Counter is only required if IO4 is supported.
If IO4 is supported, then x Days Valid Key Counter is generated and
provided by a Digital Card's key database and indicates the number of
session keys in the key database which are currently not used and will still
be valid (i.e. not expired) in x days. For example, 0 Days Valid Key
Counter indicates the number of session keys in the key database which
are currently not used and not expired. 3 Days Valid Key Counter
indicates the number of session keys in the key database which are
currently not used and will still be valid in three days.
x Days Valid Key Counter for x = Trigger Replenishment Number of Days
and Force Replenishment Number of Days defined by Key Validity
Number of Days are used to trigger the replenishment of keys based on
the limits defined by the issuer (Key Counter Limits) according to the
description in Req C.116.
CPACE for Host Card Emulation Data Dictionary Version 1.0 x Days Valid Key Counter
15.03.2019 Page 186 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Annex 1 Management of Dates in Days
For the processing of the Maximum Number of Days Without CHV Check a date in the
format YYMMDD has to be converted to a date in days (the number of days elapsed since an
initial date, day 0) and it may be necessary to convert a date in days to a date in the format
YYMMDD.
According to this specification the initial date, i.e. the day 0, for a date in days shall be the
31st of December 1999 as proposed in annex E of [CPA].
The conversion of all dates in the range 1st of January 2000 through 31st of December 2099
from a date in the format YYMMDD (000101 through 991231) to a date in days (1 through
36525) and vice versa shall be supported.
This specification does not prescribe an algorithm to be used for the conversion.
An algorithm which may be used to convert a date in the format YYMMDD to a date in days
is described in annex E of [CPA].
An algorithm which may be used to convert a date in days to a date in the format YYMMDD
is described below. It is based on the algorithm described in annex E of [CPA].
Let
1 <= n <= 36525 be a date in days and
YYMMDD the respective date in the format YYMMDD.
According to annex E of [CPA] the following holds:
n = YY*365 + [(YY + 3) div 4] + D, where D is the number of days elapsed in the year YY,
that is, from the 1st of January 20YY until the date indicated by YYMMDD.
If s := n div 365 and r := n mod 365, then
s = YY and r = [(YY + 3) div 4] + D, if and only if [(YY + 3) div 4] + D < 365
s = YY + 1 and r = [(YY + 3) div 4] + D - 365, if and only if [(YY + 3) div 4] + D >= 365
Note, that the following is true:
If YY is a multiple of 4, then 1 <= D <= 366 and [(YY + 4) div 4] = [(YY + 3) div 4] + 1
If YY is not a multiple of 4, then 1 <= D <= 365 and [(YY + 4) div 4] = [(YY + 3) div 4]
Consequently,
YY = s, if and only if r > [(s + 3) div 4]
YY = s - 1, if and only if r <= [(s + 3) div 4]
CPACE for Host Card Emulation Data Dictionary Version 1.0 x Days Valid Key Counter
15.03.2019 Page 187 © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,
Groupement des Cartes Bancaires CB, SIBS MB, STMP. All rights reserved
Therefore the year 00 <= YY <= 99 of the date in the format YYMMDD and the number of
days D elapsed in the year YY are determined in the following way from the respective date
n in days:
If n mod 365 <= ([n div 365] + 3) div 4, then YY := [n div 365] - 1
If n mod 365 > ([n div 365] + 3) div 4, then YY := n div 365
D := n - YY*365 - [(YY + 3) div 4]
According to annex E of [CPA] the following holds:
D = d + DD, where d is the number of days in the months previous to MM.
The month table defined in annex E of [CPA] is used to determine d:
MM 01 02 03 04 05 06 07 08 09 10 11 12
d(MM) 0 31 59 90 120 151 181 212 243 273 304 334
If YY is a multiple of 4 and MM is greater than 2, then d = d(MM) + 1.
Else, d = d(MM).
A slightly extended month table is used to determine the month 01 <= MM <= 12 and the day
DD of the date in the format YYMMDD in the following way from the number of days D in the
year YY:
MM 01 02 03 04 05 06 07 08 09 10 11 12 13
d(MM) 0 31 59 90 120 151 181 212 243 273 304 334 365
If YY is a multiple of 4 and D is greater than 59, then MM is the value according to the
month table, where d(MM) < D - 1 <= d(MM + 1).
Else, MM is the value according to the month table, where d(MM) < D <= d(MM + 1).
If YY is a multiple of 4 and MM is greater than 2, then DD := D - d(MM) - 1.
Else, DD := D - d(MM).