common payment application contactless …...cpace for host card emulation table of contents version...

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


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



15.03.2019 Page iii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page iv © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page v © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page vi © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page vii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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,


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


15.03.2019 Page ix © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page x © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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,


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


15.03.2019 Page xii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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


15.03.2019 Page xiii © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,


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.82 Data field in first GENERATE AC response message .................................... 84


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



15.03.2019 Page xiv © 2016-2019 Bancomat, Bancontact Payconiq Company, BankAxept, Borica, girocard/SRC,



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,


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




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.




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




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.




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


Perform Profile Selection,

provide AIP and AFL


Provide FCI

(see Section 5.3.3.2 of this specification)

Provide list ist of supported applications


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,


No

SELECT AID

Command/Response

Provide FCI


Figure 2: Contactless Transaction Flow




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



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



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


Book 2, Security and Key Management, Version 4.3, November 2011


Book 3, Application Specification, Version 4.3, November 2011


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



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.

https://en.wikipedia.org/wiki/Software_development

https://en.wikipedia.org/wiki/Application_software

https://en.wikipedia.org/wiki/Software




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




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



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




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




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



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



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



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-




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




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




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



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



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



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



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



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




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




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




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.


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.


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:






or the same DF Name is contained in two AID Entries in the same AID Table,


shall respond with an SW1 SW2 that indicates an error, and should respond with

SW1 SW2 = '6985' (Conditions of use not satisfied).




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.




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:







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.




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



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



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


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.





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




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



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.




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.


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.


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.




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.


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,


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.






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.


P is equal to 0,

or P and L would require extracting data beyond the length of the Extended GPO

Input Data,


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


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


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.




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.


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,



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.


No CVM MaxAmount is missing,

or the No CVM MaxAmount does not have the format n 12,






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.


8. Check Type '93' indicates that the No CVM Counter shall be used. In this case, the

following steps shall be performed:


No CVM Counter is missing,

or the length of No CVM Counter is different from 1 byte,



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.


No CVM MaxNumber is missing,

or the length of No CVM MaxNumber is different from 1 byte,



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.





9. Check Type '40' indicates that the CHV Limit shall be used. In this case, the following

steps shall be performed:


Issuer CHV Limit is missing,

or Issuer CHV Limit does not have the format n 12,



b) The Issuer CHV&C Control shall be retrieved.


Issuer CHV&C Control is missing,

or the length of Issuer CHV&C Control is different from 4 bytes,



c) If 'Cardholder CHV Limit' in Issuer CHV&C Control = APPLICABLE, then the

Cardholder CHV Limit shall be retrieved.


'Cardholder CHV Limit' in Issuer CHV&C Control = NOT APPLICABLE,


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


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,






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



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



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




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



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


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


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



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



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



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



8.2 First GENERATE AC Command


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


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




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.


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:


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.




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 13 - 14 Terminal Country Code 2 n 3


Bytes 20 - 21 Transaction Currency Code 2 n 3

Bytes 22 - 24 Transaction Date 3 YYMMDD

Byte 25 Transaction Type 1 n 2


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


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





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




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:


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.




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.


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




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.


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,


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.





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


to 1b.

In any case, processing shall continue with the second presentment check (Req C.52).




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




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



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




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,


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,


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,


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




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.


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.




If 'Cardholder CHV Limit' in Issuer CHV&C Control = APPLICABLE, then the

Cardholder CHV Limit shall be retrieved.


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


CHV Limit = 0,

or Transaction Currency Code does not match CHV&C Currency Code (bytes 2-

3 of Issuer CHV&C Control),


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,


In any case, processing shall continue with the No CVM Accumulator check (Req C.57).




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



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




Req C.58 No CVM Counter 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




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




Req C.59 Maximum Number of Days Without CHV check


provides the issuer notification of whether the Number of Days Without CHV Limit is

exceeded,


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,


In any case, processing shall continue with the Online PIN requested check

(Req C.60).

Req C.60 Online PIN requested check


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


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




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


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


to 1b,

and processing shall continue with the cardholder confirmation check (Req C.63).




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:


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,


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,


'Issuer Forced 2nd Presentment Setting' in Issuer CHV&C Control =

REQUIRED FOR CHV or REQUIRED FOR CHV & CHC


'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




then

'CDCVM cardholder verification required' (byte 2, bit b1) in CHV&CS shall be set to

1b (CDCVM cardholder verification required),


"Second presentment required",



else

'CDCVM Cardholder Verification Performed' (byte 2, bit b4) in the Card Verification

Results (CVR) shall be set to 1b,



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,




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,


online authorisation.




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


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.


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.


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.




If and only if both of the following are true:

CHC Limit < '99..99',


CHC Limit = 0,

or Transaction Currency Code does not match CHV&C Currency Code (bytes 2-

3 of Issuer CHV&C Control),


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.




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


1b,





Else, i.e. if cardholder confirmation information provided by the Mobile Payment App may be

used, then processing of this check continues as follows:


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,


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


Transaction History.Second Presentment Indicator does not indicate "Second

presentment required" (this is a first presentment),


'Issuer Forced 2nd Presentment Setting' in Issuer CHV&C Control =

REQUIRED FOR CHV & CHC


'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




then

'Cardholder confirmation (ACK) required' (byte 2, bit b2) in CHV&CS shall be set to

1b (Cardholder confirmation required)


"Second presentment required"



else

'Cardholder Confirmed' (byte 5, bit b6) in the Card Verification Results (CVR) shall

be set to 1b,



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,






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


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.




Req C.66 Increment No CVM Counter


No CVM Counter is active for the transaction (see Req C.50),


'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




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,


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.




Req C.68 Reset No CVM Counter






and 'Reset No CVM Counter with Successful CHV' (byte 3, bit b7) in the No

CVM Counter Profile Control has the value 1b,





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.




Req C.69 Update Last CHV Date in Days


the Maximum Number of Days Without CHV Check is active for the transaction (see

Req C.51),




and 'Update Last CHV Date in Days with Successful CHV' (byte 9, bit b4) in

the Issuer Options Profile Control has the value 1b,





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





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




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


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.




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)




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.



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.



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.


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.





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.


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





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.




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,


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




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.




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


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.




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



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


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



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



9.3 Second GENERATE AC Command


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


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




consisting of the data elements listed in Table 19, in the order shown. In particular, the IATD

has a length of 8 bytes.




consisting of the data elements listed in Table 20, in the order shown.










Format

Bytes 1 - 8 Issuer Authentication Data (IATD) 8 b

Bytes 9 - 10 Authorisation Response Code (ARC) 2 an 2





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


Format

Bytes 1 - 8 Issuer Authentication Data (IATD) 8 b





Table 20: Second GENERATE AC Command Data Field: No Amounts in CDOL2





Format

Bytes 1 - 16 Issuer Authentication Data (IATD), possibly padded 16 b







Table 21: Second GENERATE AC Command Data Field: Amounts and Proprietary

Authentication Data in CDOL2


Format

Bytes 1 - 16 Issuer Authentication Data (IATD), possibly padded 16 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.




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.


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



P2).


If the P2 parameter is not set to the value '00', CPACE-HCE EMV processing shall



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




Req C.90 Check value of Lc using Application Control and Issuer Options

Profile Control



'Proprietary Authentication Data in IATD Supported' in the Issuer Options Profile



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





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




Req C.91 Validation of the second GENERATE AC command data field




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,



'6985' (Conditions of use not satisfied).




The length LP of the Proprietary Authentication Data (PAD) shall be determined in the

following way:


'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:




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.




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'


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.




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:



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




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:



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




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


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.




Req C.103 Update No CVM Counter


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


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


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.




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.




9.3.7 Respond to GENERATE AC Command


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'


Else, CPACE-HCE EMV processing shall compute the Application Cryptogram with

the session key that is returned.




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


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



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



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



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.




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.




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





Static Issuer Data Optional

UI Module Data

UI Module Data Entry x

Optional

Table 25: Configuration Data of a Digital Card


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'




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



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





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





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:


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



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.




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


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





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


- - DD No

Second Presentment Timeout - - CD C

CPACE for Host Card Emulation Data Dictionary Version 1.0 AID Selected




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


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



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



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



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


Format: Numbered List



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



12.3.1 AIP/AFL Entry x

Template: -

Tag: -

Length (in bytes): var. up to 63

Format: b



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



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'


Format: n 12


Description: Secondary amount associated with the transaction representing a

cashback amount.

12.6 Application Control

Template: -

Tag: -


Format: b



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.


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




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'


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'


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'


Format: an 2


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)



12.10 Card Status Update (CSU)

Template: -

Tag: -


Format: b


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)




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)



12.11 Card Verification Results (CVR)

Template: -

Tag: -


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.


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)




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



12.12 Cardholder CHC Limit

Template: -

Tag: -


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



12.13 Cardholder CHV Limit

Template: -

Tag: -


Format: n 12


Provision: Optional


Control, the Cardholder CHV Limit is the cardholder defined limit for the

transaction amount, below which cardholder verification is not required.



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.


'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


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



12.14 Cardholder CHV&C Control

Template: -

Tag: -


Format: b


Provision: Optional


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.


'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


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




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


Format: b


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



12.16 Cardholder Confirmation History

Template: -

Tag: -


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



12.17 Cardholder Confirmation Timeout

Template: -

Tag: -


Format: b


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,


'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



12.18 Cardholder Confirmation Usage Limit

Template: -

Tag: -


Format: n 2



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



Digital Card,


'Issuer CHC Limit' in Issuer CHV&C Control = APPLICABLE,


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'


Format: b


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)




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



12.20 Cardholder Verification Data

Template: -

Tag: -


Format: b


Description: Cardholder Verification Data is a transaction data element which may be


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'


Format: b


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



12.22 CDCVM Cardholder Verification History

Template: -

Tag: -


Format: n 14



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


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



12.23 CDCVM Cardholder Verification Timeout

Template: -

Tag: -


Format: b



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


Format: n 2



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



12.25 CHC Limit

Template: -

Tag: -


Format: n 12


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


Format: n 12


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


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



12.28 CHV Required for This Transaction

Template: -

Tag: -


Format: b


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


12.29 Cryptogram Information Data (CID)

Template: -

Tag: '9F27'


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:


Format: b


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



12.31 Dynamic Issuer Data

Template: -

Tag: 'D1'


Format: b


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


Format: b


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



12.33 GPO Input Data Length

Template: -

Tag: -


Format: b


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





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)



12.34.1 GPO Parameters x

Template: -

Tag: -


Format: b



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'


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)



12.36 Issuer Authentication Data (IATD)

Template: -

Tag: '91'

Length (in bytes): 8-16

Format: b


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



12.37 Issuer CHC Limit

Template: -

Tag: -


Format: n 12


Provision: Optional


Control, the Issuer CHC Limit is the issuer defined limit for the transaction

amount, below which cardholder confirmation is not required.



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.


'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



12.38 Issuer CHV Limit

Template: -

Tag: -


Format: n 12




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.



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,



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



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



12.39 Issuer CHV&C Control

Template: -

Tag: -


Format: b



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




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


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




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


Format: b


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





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



12.41.1 Issuer Options Profile Control x

Template: -

Tag: -


Format: b



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.




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


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





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




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


Table 48: Proprietary Issuer Options Profile Parameters

12.42 Key Counter

Template: -

Tag: -


Format: b



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


Format: b



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



12.44 Key Validity Number of Days

Template: -

Tag: -


Format: b


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



12.45 Last CHV Date in Days

Template: -

Tag: -


Format: b



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


CPACE for Host Card Emulation Data Dictionary Version 1.0 No CVM Accumulator



12.46 No CVM Accumulator

Template: -

Tag: -


Format: n 12



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


Format: n 12


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



12.48 No CVM Accumulator Control

Template: -

Tag: -


Format: b



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.


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


Format: b


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



12.50 No CVM Accumulator Profile Controls

Template: -

Tag:





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


Format: b


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.


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




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



12.51 No CVM Counter

Template: -

Tag: -


Format: b



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:


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


Format: b



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




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


Format: b


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





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



12.54.1 No CVM Counter Profile Control x

Template: -

Tag: -


Format: b



Description: No CVM Counter Profile Control x indicates the issuer's choice of data

and behaviour to configure No CVM Counter within a Profile.


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.


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



12.55 No CVM MaxAmount

Template: -

Tag: -


Format: n 12



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


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


Format: b



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



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



12.57 Number of Days Without CHV Limit

Template: -

Tag: -


Format: n 4



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


12.58 Online Parameter

Template: '77'

Tag: '9F55'


Format: b


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.


1 - - - - - - - Restart Expected

- x x x x x x x RFU

CPACE for Host Card Emulation Data Dictionary Version 1.0 PDOL Related Data



Table 55: Online Parameter Coding

12.59 PDOL Related Data

Template: -

Tag: '83'


Format: b


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


Format: b



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




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


Format: b


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





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



12.62.1 Profile Control x

Template: -

Tag: -


Format: b


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.


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.


1 x x x x - - - - Issuer Options Profile Control ID

- - - - x x x x AIP/AFL ID


- - - - x x x x No CVM Accumulator Profile Control ID


- - - - x x x x No CVM Counter Profile Control ID






Table 57: Profile Control x Coding

CPACE for Host Card Emulation Data Dictionary Version 1.0 Profile ID



12.63 Profile ID

Template: -

Tag: -


Format: b


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



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


Format: b


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



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'





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





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



Input Data is less than comparison

value 1 in this Profile Selection Entry.

Greater Than (Check Type = '02')



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





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


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


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)



12.65 Proprietary Authentication Data (PAD)

Template: -

Tag: -


Format: b


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


Description: Recent Cardholder Confirmation is a transaction data element which is


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



12.67 Recent CDCVM Cardholder Verification

Template: -

Tag: -


Format: -


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


Format: b


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



12.69 Restart Indicator

Template: -

Tag: -


Format: b



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


Format: b



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



12.71 Second Presentment Timeout

Template: -

Tag: -


Format: b



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



Digital Card,


'Issuer CHC Limit' in Issuer CHV&C Control =

APPLICABLE,


APPLICABLE.

CPACE for Host Card Emulation Data Dictionary Version 1.0 Static Issuer Data



12.72 Static Issuer Data

Template: -

Tag: 'D0'


Format: b


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'


Format: n 3


Description: Indicates the country of the terminal, represented according to [ISO 3166-

1].

12.74 Terminal Risk Management Data

Template: -

Tag: '9F1D'


Format: b


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




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




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









Table 62: Terminal Risk Management Data

12.75 Terminal Type

Template: -

Tag: '9F35'


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'


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



12.77 Time of First Presentment

Template: -

Tag: -


Format: -


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


Format: n 12


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



12.79 Transaction Currency Code

Template: -

Tag: '5F2A'


Format: n 3


Description: Transaction Currency Code indicates the currency code of the transaction

according to [ISO 4217].

12.80 Transaction CVM

Template: -

Tag: -


Format: b


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)


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'


Format: n 6 (YYMMDD)


Description: Local date that the transaction was authorised.

CPACE for Host Card Emulation Data Dictionary Version 1.0 Transaction History



12.82 Transaction History

Template: -

Tag: -


Format: Structure



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



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'


Format: n 2


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'


Format: b


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



12.85 UI Module Data

Template: -

Tag: -

Length (in bytes): not applicable.



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


Format: b

Provision: Optional

Description: Meaning, length and format of these data elements are determined by the

issuer.


CPACE for Host Card Emulation Data Dictionary Version 1.0 x Days Valid Key Counter



12.86 x Days Valid Key Counter

Template: -

Tag: -


Format: b



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.




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]




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

common payment application contactless …...cpace for host card emulation table of contents version...

Documents