Part II Debit Credit Application Card Specification

UnionPay Integrated Circuit Card Specifications
— Basic Specifications
Part II Debit/Credit Application Card Specification
V1.0.2
THIS PAGE IS INTENTIONALLY LEFT BLANK.
PartII Debit/Credit Application Card Specification
Table of Contents
SUMMARY OF REVISIONS.................................................................................................... 1
1 APPLICATION SCOPE ...................................................................................................... 2
2 REFERENCES ..................................................................................................................... 3
3 OVERVIEW 4
3.1 FUNCTION OVERVIEW ....................................................................................................... 4
3.1.1 Application Selection (Mandatory) .................................................................... 4
3.1.2 Application Initialization/Read Application Data (Mandatory) ........................ 4
3.1.3 Offline Data Authentication (Optional) ............................................................. 4
3.1.4 Processing Restriction (Mandatory) .................................................................. 5
3.1.5 Cardholder Verification (Optional) .................................................................... 5
3.1.6 Terminal Risk Management (Mandatory) .......................................................... 5
3.1.7 Terminal Action Analysis (Mandatory) .............................................................. 5
3.1.8 Card Action Analysis (Mandatory) .................................................................... 6
3.1.9 Online Processing (Optional) ............................................................................ 6
3.1.10 Transaction Completion (Mandatory)................................................................ 7
3.1.11 Issuer- to-Card Script Processing (Optional) .................................................... 7
3.2 MANDATORY AND OPTIONAL FUNCTIONS ......................................................................... 8
3.2.1 Card Function Requirements ............................................................................. 8
3.2.2 Command Support Requirement ...................................................................... 10
4 APPLICATION SELECTION .......................................................................................... 12
4.1 CARD DATA .................................................................................................................... 12
4.2 TERMINAL DATA ............................................................................................................. 14
4.3 COMMAND ...................................................................................................................... 15
4.4 ESTABLISH CANDIDATE APPLICATION LIST ..................................................................... 16
4.4.1 Directory Selection Method ............................................................................. 16
4.4.2 AID List Selection Method ............................................................................... 17
4.5 APPLICATION IDENTIFICATION AND SELECTION .............................................................. 18
4.6 FLOW CHART .................................................................................................................. 19
4.7 SUBSEQUENT RELATED PROCESSING .............................................................................. 20
UPI Confidential i
5 APPLICATION INITIALIZATION ................................................................................. 21
5.1 CARD DATA .................................................................................................................... 21
5.2 TERMINAL DATA ............................................................................................................. 22
5.3 COMMAND ...................................................................................................................... 22
5.4 PROCESSING FLOW ......................................................................................................... 23
5.5 PRIOR RELATED PROCESSING ......................................................................................... 24
6 READ APPLICATION DATA........................................................................................... 26
6.1 CARD DATA .................................................................................................................... 26
6.2 TERMINAL DATA ............................................................................................................. 27
6.3 COMMAND ...................................................................................................................... 27
6.4 PROCESSING FLOW ......................................................................................................... 27
7 OFFLINE DATA AUTHENTICATION ........................................................................... 28
7.1 KEY AND CERTIFICATE .................................................................................................... 28
7.2 DETERMINING THE METHOD OF OFFLINE DATA AUTHENTICATION ................................. 28
7.2.1 Card Data ........................................................................................................ 28
7.2.2 Processing ........................................................................................................ 29
7.3 STATIC DATA AUTHENTICATION (SDA) ........................................................................... 29
7.3.1 Card Data ........................................................................................................ 29
7.3.2 Terminal Data .................................................................................................. 32
7.3.3 Command ......................................................................................................... 32
7.3.4 Processing Flow ............................................................................................... 32
7.4 DYNAMIC DATA AUTHENTICATION (DDA) ..................................................................... 33
7.4.1 Card Data ........................................................................................................ 33
7.4.2 Terminal Data .................................................................................................. 34
7.4.3 Command ......................................................................................................... 35
7.4.4 Processing ........................................................................................................ 35
UPI Confidential ii
8 PROCESSING RESTRICTION ....................................................................................... 39
8.1 CARD DATA .................................................................................................................... 39
8.2 TERMINAL DATA ............................................................................................................. 39
8.3 PROCESSING ................................................................................................................... 40
8.3.1 Application Version Number Check ................................................................. 40
8.3.2 Application Usage Control check .................................................................... 40
8.3.3 Application Effective Date Check .................................................................... 42
8.3.4 Application Expiration Date Check ................................................................. 42
9 CARDHOLDER VERIFICATION................................................................................... 43
9.1 CARD DATA .................................................................................................................... 43
9.2 TERMINAL DATA ............................................................................................................. 47
9.3 COMMAND ...................................................................................................................... 48
9.4 PROCESSING ................................................................................................................... 48
9.4.1 CVM List Processing ....................................................................................... 48
9.4.2 Offline Plaintext PIN Processing ..................................................................... 48
9.4.3 Processing of Other CVMs ............................................................................... 52
10 TERMINAL RISK MANAGEMENT .............................................................................. 54
10.1 CARD DATA .................................................................................................................... 54
10.2 TERMINAL DATA ............................................................................................................. 55
10.3 COMMAND ...................................................................................................................... 56
10.4 PROCESSING ................................................................................................................... 56
10.4.1 Terminal Exception File Check ........................................................................ 57
10.4.2 Merchant Forced Transaction Online .............................................................. 57
10.4.3 Floor Limit Check ............................................................................................ 57
10.4.4 Random Transaction Selection ......................................................................... 57
UPI Confidential iii

10.4.5 Terminal Velocity Check ................................................................................... 57
10.4.6 New Card Check .............................................................................................. 57
11 TERMINAL ACTION ANALYSIS ................................................................................... 59
11.1 CARD DATA .................................................................................................................... 59
11.2 TERMINAL DATA ............................................................................................................. 60
11.3 COMMAND ...................................................................................................................... 61
11.4 PROCESSING ................................................................................................................... 61
11.4.1 Offline Processing Result Check ...................................................................... 61
11.4.2 Cryptogram Request ........................................................................................ 61
12 CARD ACTION ANALYSIS ............................................................................................. 63
12.1 CARD DATA .................................................................................................................... 63
12.2 TERMINAL DATA ............................................................................................................. 66
12.3 COMMAND ...................................................................................................................... 67
12.4 PROCESSING ................................................................................................................... 67
12.4.1 Card Receives Cryptogram Request ................................................................ 67
12.4.2 Card Risk Management .................................................................................... 68
12.4.3 Card Risk Management Process ...................................................................... 70
12.5 CARD PROVIDES RESPONSE CRYPTOGRAM ..................................................................... 75
12.5.1 Card Declined Transaction Offline .................................................................. 76
12.5.2 Card Requested for Online Processing ............................................................ 76
12.5.3 Card Approved Transaction Offline ................................................................. 77
12.5.4 Combined Dynamic Data Authentication Application Cryptogram

Generation Requested ...................................................................................... 77
12.6 PROCESSING FLOW ......................................................................................................... 79
UPI Confidential iv
13 ONLINE PROCESSING ................................................................................................... 86
13.1 CARD DATA .................................................................................................................... 86
13.2 ONLINE RESPONSE DATA ................................................................................................ 87
13.3 COMMAND ...................................................................................................................... 88
13.4 PROCESSING ................................................................................................................... 88
13.4.1 Online Request ................................................................................................. 88
13.4.2 Online Response............................................................................................... 88
13.4.3 Issuer Authentication ....................................................................................... 89
13.5 PROCESSING FLOW ......................................................................................................... 90
14 COMPLETION .................................................................................................................. 92
14.1 CARD DATA .................................................................................................................... 92
14.2 TERMINAL DATA ............................................................................................................. 95
14.3 COMMAND ...................................................................................................................... 96
14.4 COMPLETION PROCESSING OVERVIEW ............................................................................ 96
14.5 RECEIVE GENERATE AC COMMAND ............................................................................ 97
14.6 TRANSACTION AUTHORIZED ONLINE .............................................................................. 98
14.6.1 AAC (Decline) Requested after Online Authorization ..................................... 98
14.6.2 TC (Approval) Requested after Online Authorization ...................................... 99
14.7 ONLINE PROCESSING REQUESTED, BUT ONLINE AUTHORIZATION NOT COMPLETED .... 102
14.7.1 Card Risk Management .................................................................................. 103
14.7.2 Card Response after Unable to Go Online .................................................... 105
14.8 RESPONSE TO COMBINED DYNAMIC DATA AUTHENTICATION/ GENERATE

APPLICATION CRYPTOGRAM ......................................................................................... 107
14.9 FLOW CHART ................................................................................................................ 108
14.10 PRIOR RELATED PROCESSING ........................................................................................112
14.11 SUBSEQUENT RELATED PROCESSING .............................................................................113
15 ISSUER-TO-CARD SCRIPT PROCESSING ................................................................114
15.1 CARD DATA ...................................................................................................................114
UPI Confidential v
15.2 TERMINAL DATA ............................................................................................................115
15.3 KEY MANAGEMENT DURING ISSUER SCRIPT PROCESSING .............................................116
15.4 AUTHORIZATION RESPONSE DATA .................................................................................118
15.5 COMMAND .....................................................................................................................118
15.6 PROCESSING ................................................................................................................. 121
15.6.1 Authorization Response Message ................................................................... 121
15.6.2 Card Script Processing .................................................................................. 121
15.6.3 Card Secure Messaging ................................................................................. 121
15.6.4 Resulting Indicators ....................................................................................... 122
15.6.5 Processing Flow ............................................................................................. 122
15.7 PRIOR RELATED PROCESSING ....................................................................................... 123
15.8 SUBSEQUENT RELATED PROCESSING ............................................................................ 124
16 CARD RECORDS TRANSACTION DETAILS ........................................................... 125
16.1 TRANSACTION DETAIL RECORD FILE ............................................................................ 125
16.2 UNIONPAY SUGGESTIONS.............................................................................................. 125
17 CONTACT LOW-VALUE PAYMENT FUNCTION BASED ON DEBIT/CREDIT

APPLICATION ................................................................................................................ 127
17.1 TECHNICAL REQUIRE ADDITIONAL DATA ELEMENTS ..................................................... 127
17.1.1 Add Data Elements ........................................................................................ 127
17.1.2 Card Offline Data Authentication .................................................................. 128
17.1.3 Principles of Cardholder Verification Method ............................................... 128
17.1.4 Transaction Log ............................................................................................. 128
17.1.5 Currency Conversion ..................................................................................... 129
17.1.6 Data Element Usage ...................................................................................... 129
17.1.7 Load Log ........................................................................................................ 129
17.2 DEFINITION OF BALANCE.............................................................................................. 130
17.3 TRANSACTION PROCESSING .......................................................................................... 130
17.3.1 Application Selection ..................................................................................... 131
17.3.2 Application Initialization ............................................................................... 131
17.3.3 Terminal Risk Management............................................................................ 132
UPI Confidential vi
17.3.4 Terminal Action Analysis ............................................................................... 132
17.3.5 Card Action Analysis ...................................................................................... 132
17.3.6 End of Transaction ......................................................................................... 133
17.4 TRANSACTION FLOW CHART ........................................................................................ 135
17.5 CARD COMMAND .......................................................................................................... 136
17.5.1 Electronic Cash Balance Inquiry ................................................................... 136
17.5.2 Transaction Log Inquiry ................................................................................ 137
17.5.3 Command of Obtaining Transaction Log formats .......................................... 140
17.5.4 Update Electronic Cash Parameter Command .............................................. 141
APPENDIX A DEFINITION OF CARD AND ISSUER DATA ELEMENTS ........... 143
A.1 CARD AND ISSUER DATA ELEMENTS DESCRIPTIONS ..................................................... 143
A.2 CARD AND ISSUER DATA ELEMENTS REQUIREMENTS ................................................... 177
A.2.1 Tag ................................................................................................................. 177
A.2.2 Requirements Presence .................................................................................. 177
A.2.3 Data Integrity (Backup Required) .................................................................. 177
A.2.4 Update Capability .......................................................................................... 177
A.2.5 Retrieval Capability ....................................................................................... 177
A.2.6 Static or Dynamic........................................................................................... 178
A.2.7 Secret Data..................................................................................................... 178
A.2.8 ADF Data ....................................................................................................... 178
A.2.9 Data Requirement List ................................................................................... 179
A.2.10 Data Requirement list - Condition Number List ............................................ 195
A.3 REGULATIONS ON THE DEFINITION OF CARD AND ISSUER DATA ELEMENT ................... 197
APPENDIX B COMMAND SPECIFICATION ........................................................... 200
B.1 BASIC PROCESSING RULES FOR ISSUER SCRIPT COMMAND .......................................... 200
B.2 APPLICATION BLOCK COMMAND C-APDU/R-APDU ............................................ 201
B.2.1 Definition and Applicable Scope .................................................................... 201
B.2.2 Command Message ........................................................................................ 201
B.2.3 Data Field of Command Message .................................................................. 201
B.2.4 Data Field of the Response Message ............................................................. 202
UPI Confidential vii

B.2.5 Processing Status of Response Message ........................................................ 202
B.3 APPLICATION UNBLOCK COMMAND C-APDU/R-APDU ...................................... 202
B.3.5 Processing Status Returned by the Response Message .................................. 203
B.4 CARD BLOCK COMMAND C-APDU/R-APDU .......................................................... 203
B.5 EXTERNAL AUTHENTICATE COMMAND C-APDU/R-APDU ................................ 204
B.6 GENERATE APPLICATION CRYPTOGRAM COMMAND C-APDU/R-APDU .................. 205
B.6.5 Processing Status Returned by the Response Message. ................................. 209
B.7 GET DATA COMMAND C-APDU/R-APDU ................................................................. 209
B.7.1 Definition and applicable scope .................................................................... 209
B.7.2 Command Message ......................................................................................... 211
B.7.3 Data Field of Command Message ................................................................... 211
B.7.4 Data Field of the Response Message .............................................................. 211
UPI Confidential viii

B.7.5 Processing Status Returned by the Response Message ................................... 211
B.8 GET PROCESSING OPTIONS COMMAND C-APDU/R-APDU ..................................211
B.8.1 Definition and Applicable Scope ..................................................................... 211
B.8.5 B.8.5 Processing status Returned by the Response Message ......................... 213
B.9 INTERNAL AUTHENTICATE COMMAND C-APDU/R-APDU ................................. 213
B.10 PIN CHANGE / UNBLOCK COMMAND C-APDU/R-APDU ...................................... 214
B.11 PUT DATA COMMAND C-APDU/R-APDU ................................................................. 218
B.12 READ RECORD COMMAND C-APDU/R-APDU ........................................................ 220
UPI Confidential ix
B.13 SELECT COMMAND C-APDU/R-APDU ..................................................................... 222
B.13.3 Data field of command message .................................................................... 223
B.13.4 Data Field of Response Message ................................................................... 223
B.13.5 Status Code of Response Message ................................................................. 225
B.14 UPDATE RECORD COMMAND C-APDU/R-APDU.................................................... 225
B.14.2 Command message......................................................................................... 225
B.14.4 Data field of the Response Message............................................................... 226
B.15 VERIFY COMMAND C-APDU/R-APDU ..................................................................... 227
B.15.5 Processing Status in the Response Message .................................................. 230
APPENDIX C SECURE MESSAGING ........................................................................ 231
C.1 FORMAT OF SECURE MESSAGING .................................................................................. 231
C.2 MESSAGE INTEGRITY AND AUTHENTICATION (MACING) ............................................. 231
C.2.1 MAC Location ................................................................................................ 231
C.2.2 MAC Length ................................................................................................... 231
C.2.3 MAC Key Generation ..................................................................................... 231
C.2.4 MAC Calculation ........................................................................................... 231
C.3 DATA CONFIDENTIALITY ............................................................................................... 233
C.3.1 Data Encipherment Key Calculation ............................................................. 233
C.3.2 Structure of Enciphered Data ......................................................................... 233
C.3.3 Data Encipherment Calculation .................................................................... 233
UPI Confidential x
C.3.4 Data Decipherment Calculation .................................................................... 235
C.4 SESSION KEY GENERATION ........................................................................................... 236
APPENDIX D AUTHENTICATION KEY AND ALGORITHM ............................... 237
D.1 DATA SOURCE ............................................................................................................... 237
D.2 GENERATING THE TC\AAC\ARQC .............................................................................. 238
D.3 GENERATING THE AUTHORIZATION RESPONSE CRYPTOGRAM (ARPC) ......................... 239
D.4 DERIVATION KEY METHODOLOGY ................................................................................ 241
APPENDIX E SUPPORTED CRYPTOGRAM VERSION ........................................ 243
APPENDIX F ALGORITHM IDENTIFICATION ..................................................... 244
APPENDIX G (EXPLANATORY APPENDIX)ACCOUNT MANAGEMENT

UNDER LOW-VALUE PAYMENT FUNCTION .......................................................... 245
G.1 OFFLINE TRANSACTION ................................................................................................ 246
G.2 ONLINE TRANSACTION ................................................................................................. 247
APPENDIX H (INFORMATIVE APPENDIX) ELECTRONIC -CASH

BALANCE AND LOG READER.................................................................................... 251
H.1 OVERVIEW .................................................................................................................... 251
H.1.1 Overview of Requirements ............................................................................. 251
H.1.2 Overview of Requirements ............................................................................. 251
H.1.3 Security Requirements .................................................................................... 252
H.2 OVERVIEW OF FUNCTIONALITY .................................................................................... 252
H.2.1 Electronic Cash Balance ................................................................................ 252
H.2.2 Obtaining Electronic Cash Balance Using GET DATA Command ................ 252
H.2.3 Displaying Transaction Log ........................................................................... 252
H.3 FUNCTIONAL REQUIREMENTS ....................................................................................... 253
H.3.1 Electronic Cash Balance ................................................................................ 253
H.3.2 Transaction Log ............................................................................................. 254
UPI Confidential xi
Summary of Revisions
The change listed below is associated with the current version.
Description of Change Where to look

Added: “Cardholder Name” and “Cardholder Name
extended” with a note section: “The value of this data
object can be Chinese characters, and it may cause A.1
transaction rejections on a limited number of
terminals outside Mainland China.”
Revised: Updated “'80' to '9E' and '9F01' to '9F7F' are
reserved by EMV.” to “'80' to '9E' and '9F01' to '9F4F'
A.3
are reserved by EMV”. “9F50” to “9F7F” are
reserved for this specification.
Added: For SELECT command, invalid application shall
return FCI and status byte “The file selected is B.2.1
invalid” (SW1 SW2='6283').
Revised: Updated “After the card responds an AAC to the 1st
GENERATE AC Command, the device must be able
to send the transaction online. Even if the card
supports issuer authentication, it is not necessary to
perform.” to “After the card responds an AAC to the
15.5
1st GENERATE AC Command, the device should be
able to send the transaction online, regardless of
whether the Issuer authentication is executed, the card
should be able to process APPLICATION
UNBLOCK command properly.”
UPI Confidential 1
1 Application Scope
This book applies to all UPI Participants.
UPI Confidential 2
2 References
The terms and conditions of the following documents quoted in this book have
become the terms and conditions of the Specification. The modification list
(excluding corrected contents) or revised edition attached to the dated documents
shall not apply to this book. However, Participants may study whether to apply the
latest versions of such documents. The latest versions of non-dated documents shall
apply to this book.
EMV Integrated Circuit Card Specifications for Payment Systems, Version 4.3
Book 1 Application Independent ICC to Terminal Interface Requirements
Book 2 Security_and_Key_Management
Book 3 Application Specification
ISO 3166-1:1997 ISO 3166-1:1997 Codes for the representation of names of

countries and their subdivisions -- Part 1: Country codes
ISO/IEC 639-1:2002 ISO/IEC 639-1:2002 Codes for the representation of names

of languages -- Part 1: Alpha-2 code
ISO 4217:2001 ISO 4217:2001 Codes for the representation of currencies and
funds
ISO 8583:1987 ISO 8583:1987 Bank card originated messages -- Interchange

message specifications -- Content for financial transactions
ISO/IEC 7816-4 ISO/IEC 7816-4:2005 Identification cards -- Integrated circuit

cards -- Part 4: Organization, security and commands for interchange
ISO/IEC 7816-5:1994 Identification cards -- Integrated circuit(s) cards with

contacts -- Part 5: Numbering system and registration procedure for application
identifiers
ISO/IEC 7816-6 Identification cards -- Integrated circuit(s) cards with contacts --

Part 6: Interindustry data elements
ISO/IEC 7813:1995 ISO/IEC 7813:1995 Identification cards -- Financial

transaction cards
ISO/IEC 8859-1~ISO/IEC 8859-10 Information Technology — 8-Bbit Single-Byte

Coded Graphic Character Sets
UICS Part III Debit/Credit Application Terminal Specification
UICS Part IV Debit/Credit Application Security Specification
UPI Confidential 3
3 Overview
This Chapter provides an overview of UnionPay IC Card debit/credit transactions.

With a transaction flow as Figure 1, it illustrates the steps that each function should
be performed during the transaction. If the Low-value Payment function based on
debit/credit application is supported, the card shall meet the requirement which
describes in section 17. It also describes the requirements of function and command
supported between the card and terminal.
3.1 Function Overview
The following sections describe the debit/credit transaction processing. They are
divided into mandatory which may be optional in some scenarios or optional. But
all of them are performed based on the parameters in the card or the terminal.
3.1.1 Application Selection (Mandatory)
When a card is inserted into a terminal, the terminal determines which applications
are supported by both the card and the terminal. The terminal detects the
applications supported by both the terminal and the card, and displays them for the
user to select. If those applications cannot be displayed on the terminal, it
automatically selects the application of the highest priority in the card as designated
by the Issuer in advance.
3.1.2 Application Initialization/Read Application Data (Mandatory)
After UnionPay IC debit/credit application is selected, the terminal will request the
card to get the chip data from the storage and the functions shall be used during a
transaction. Based on different situations (domestic or overseas), the chip data or
the supported functions may be different. The terminal reads the data indicated by
the card and uses the list of supported functions to determine the processes to be
executed.
3.1.3 Offline Data Authentication (Optional)
The terminal determines if the offline static or dynamic data authentication should
be used to authenticate a card offline based on whether the card and the terminal
support those methods.
Static Data Authentication (SDA) will validate those important personal data which
are easy to be fraudulently altered after card is issued. The terminal will use CA
public key to decrypt Issuer public key certificates and get Issuer public key. This
process is able to generate a hash value that shall be matched with the one is
encrypted by Issuer private key for ensuring those personal data are not changed.
Dynamic Data Authentication (DDA) will validate whether the important personal
data is fraudulently altered after card is issued or the card is fake. There are two
types of DDA: DDA and Combined DDA/AC Generation (CDA). For both types,
the terminal validates the card static data in a similar manner to SDA.
UPI Confidential 4
As for executing DDA, the terminal will request the card to generate a randomly
dynamic (transaction unique) data which is a digital signature and use those
retrieval of public keys to decrypt the dynamic signature cryptogram to match the
original data for ensuring the card is not a counterfeit one created with data
skimmed from a legal card.
As for executing CDA, it includes a dynamic signature such as DDA and

application cryptogram (AC) generation during card action analysis to ensure that
the application cryptogram is from a valid card.
3.1.4 Processing Restriction (Mandatory)
The terminal examines whether the application transaction is allowed to continue

through processing restrictions. The terminal checks the effective date and
expiration date of the card, the consistency between the card application versions
and the terminal, and if the application usage control (AUC) restriction is valid.
The issuer can use AUC to set whether the card can be used domestically or
internationally, or if the card can be used for cash, commodity, service or cash
back.
3.1.5 Cardholder Verification (Optional)
Cardholder verification is to confirm the legality of the cardholder and the card is
not lost or stolen. The terminal determines which verification method is to be used
via examining the card verification method list (CVMs) of the card. The issuer
establishes priorities on those cardholder verification methods and specific
cardholder verification method is adopted based on terminal capabilities and
transaction features. For instance, If CVM is offline PIN, the terminal will prompt
the cardholder to enter a PIN on the terminal and the card will check if it is valid.
The CVM list can also include online PIN, signature or no CVM required during
transaction.
3.1.6 Terminal Risk Management (Mandatory)
Terminal Risk Management checks whether the transaction has exceeded the
merchant floor limit, the account number is located in the terminal exception file,
the consecutive offline transaction time exceeds the limit, the card is a new card,
the merchant forces an online transaction, and the transaction is randomly selected
to go online or velocity checking. The terminal will use those chip data in the card
to conduct such above checks.
3.1.7 Terminal Action Analysis (Mandatory)
Terminal action analysis determines whether to approve the transaction offline,

reject the transaction offline, or send an online authorization for the transaction
according to the results of offline data authentication, processing restriction,
cardholder verification and terminal risk management as well as the risk
management parameters set in the terminal and the card. Card rules should be set in
UPI Confidential 5
Issuer action codes (IACs) field transmitted from the card to the terminal and
terminal rules set in the terminal action codes (TACs). After the transaction
processing is determined, the terminal requests application cryptogram from the
card. Different application cryptograms correspond to different transaction
processing: the transaction certificate (TC) should be interpreted as an approval,
authorization request cryptogram (ARQC) as online request and application
authentication cryptogram (AAC) as rejection. See Table 1. The terminal shall also
specify whether the transaction is eligible for CDA execution.
Table 1 Application cryptogram type
Cryptogram type
Approved transaction TC
Online transaction ARQC
Declined transaction AAC
3.1.8 Card Action Analysis (Mandatory)
After receiving the Application Cryptogram request from the terminal, the card
performs its own risk management as Card Action Analysis to determine if the
transaction processing set by the terminal should be changed and the check may
include prior incomplete online transaction, Issuer authentication failure or offline
data authentication failure on previous transaction, and the transaction counters or
amount of velocity check limits has been reached. The card can change offline
approval to online authorization or offline declined, but it cannot reverse the offline
declined decision made by terminal.
After those above checks are completed, the card uses the application data and a
secret DES key in the card to generate Application Cryptogram and return that to
the terminal. For offline approved transaction, TC and the data used to generate TC
are transmitted to the issuer in a clearing message for future cardholder disputes or
chargeback processing. TC can be used as “evidence” for verifying if the merchant
or the acquirer has changed the transaction data when the cardholder disputes a
transaction. Correspondingly, the cryptogram type is AAC as an offline declined
transaction and ARQC is requesting for online authorization.
After the card makes the conclusion of approving the transaction (the card returns
TC), the card will record the transaction logs on the chip.
3.1.9 Online Processing (Optional)
If both card and terminal determines that an online authorization is required for the
transaction and the terminal has the online capability, the terminal sends an online
UPI Confidential 6
authorization message to the issuer. The message includes ARQC Cryptogram, the
data used to generate ARQC and the indicator shows the offline processing result.
During the online processing, the issuer uses the Processing Flow named Card
Authentication Method (CAM) to verify ARQC and authenticate that card. The
issuer can consider CAM and offline processing results in its authorization
decision.
The authorization response message transmits to the terminal includes the

Authorization Response Cryptogram (ARPC) which is generated by the issuer
(based on ARQC, authorization response code and card secret DES key). This
response can also include the post-issuance update names Issuer Script.
If the authorization response includes an ARPC and the card supports issuer
authentication, the card will validate ARPC to check whether the response comes
from a true issuer (or its agent). Once the issuer authentication is validated, the card
can reset some security-related parameters in the card. This can prevent counters
and indicators to be reset through simulating online processing or fraudulently
approving transaction to attack the card. If issuer authentication is failed, the
subsequent transactions for that card must be sent online for authorization until the
issuer authentication is successful. The issuer can setup that card to decline the
transaction when the issuer authentication is failed.
3.1.10 Transaction Completion (Mandatory)
The card and the terminal perform the final processing to complete the transaction.
The card may decline a transaction approved by the issuer based on the issuer
authentication results and the issuer-encoded parameters in the card as the card risk
management. The card decides whether to reset the card based counter and
indicator (bit) according to the transaction disposition, issuer authentication results
and issuer encoded rules. The card generates TC or AAC when it approves or
declines the transaction.
If the terminal transmits a clearing message after the authorization message, TC

shall be included in the clearing message.
After the card makes the conclusion to approve the transaction (the card returns
TC), the card will record the transaction logs.
3.1.11 Issuer- to-Card Script Processing (Optional)
If the issuer includes the Script Updates in the authorization response message, the
terminal will transmit the Script Commands correctly to the card. Prior to applying
the update, the card will perform security check to ensure that the Script comes
from a valid issuer and has not been altered during the transmission. The supported
Script Command allows updating offline processing parameters, blocking and
unblocking the application, blocking the card, resetting offline PIN try counter and
changing offline PIN value.
UPI Confidential 7
Figure 1: An Example of Transaction Flow Chart
3.2 Mandatory and Optional Functions
3.2.1 Card Function Requirements
UnionPay IC debit/credit card must support the mandatory functions specified in

the table below, but optional functions can be decided by the issuer or the market.
If the situations permit, some conditional functions shall also be supported.
Table 2: Card Function Requirement
UPI Confidential 8
Function Supported by Card
Application selection Mandatory
 Directory selection mode  Optional
 Explicit selection mode  Mandatory
Application initialization Mandatory
Read application data Mandatory
Offline data authentication Optional
 SDA  Optional, conditional - if DDA is supported
 standard DDA  Optional, conditional - if CDA is supported (
 Combined DDA/Application  Optional

Cryptogram Generation
Processing restriction Mandatory
 Application version Number  Mandatory
 Application Usage Control  Optional
 Effective date check  Optional)
 Expiry date check  Mandatory
Cardholder verification Optional
 Individual CVMs  Optional
Terminal risk management Mandatory
 Terminal exceptional file check  n/a (no processing in the card)
 Merchant force online  n/a (no processing in the card)
 Floor limit check  n/a (no processing in the card)
 Transaction log  n/a (no processing in the card)
 Random selection  n/a (no processing in the card)
 Velocity check  Optional
 New card check  Optional
UPI Confidential 9
Function Supported by Card
Terminal action analysis IACs required
Card action analysis Mandatory
 Online/offline decision  Mandatory
 Card risk management  Mandatory; some card risk management steps are
optional (refer to Chapter 14 card action analysis)
 Optional
 Advice message
 multiple algorithm options provided
 Application Cryptogram
Online processing Mandatory
 Online capability  Mandatory
 Issuer authentication  Optional
transaction completion Mandatory
Issuer-to-card script processing Optional
 Secure Messaging  Two script types provided (EMV), only one script
type tag’72’ supported (UnionPay IC debit/credit)
3.2.2 Command Support Requirement
Commands supported by the card are described in the table below.
Table 3: Command Support Requirement
Command Supported by Card
APPLICATION BLOCK capacity is optional. If it is

APPLICATION BLOCK supported, APPLICATION BLOCK Command
(UnionPay IC debit/credit) is recommended.
APPLICATION UNBLOCK capacity is optional. If it

APPLICATION UNBLOCK is supported, APPLICATION UNBLOCK Command
(UnionPay IC debit/credit) is recommended.
UPI Confidential 10
Command Supported by Card
CARD BLOCK is a recommended function. CARD

CARD BLOCK BLOCK Command is a kind of method that
UnionPay IC debit/credit supports to block a card.
Conditional - if issuer authentication is supported

EXTERNAL AUTHENTICATE
(EMV).
GENERATE APPLICATION
Mandatory (EMV)
CRYPTOGRAM
Optional (EMV)
GET DATA
Mandatory (UnionPay IC debit/credit)
GET PROCESSING OPTIONS Mandatory (EMV)
INTERNAL AUTHENTICATE Conditional -if DDA is supported (EMV)
PIN UNBLOCK - mandatory, if offline is supported.

PIN CHANGE / UNBLOCK (UnionPay IC
PIN CHANGE / UNBLOCK debit/credit) can be applied.
PIN CHANGE — optional. It must be applied under

the issuer’s control (UnionPay IC debit/credit).
PUT DATA Optional (UnionPay IC debit/credit)
READ RECORD Mandatory (EMV)
SELECT Mandatory (EMV)
UPDATE RECORD Optional (UnionPay IC debit/credit)
VERIFY Conditional —if offline PIN is supported (EMV).
UPI Confidential 11
4 Application Selection
Application Selection processing determines the application that both card and
terminal support to perform a transaction. The Application Selection processing
consists of two steps:
1. The terminal establishes the application list supported by both card and
terminal;
2. A single application is identified and selected from the list to perform the
transaction.
4.1 Card Data
The card data elements and brief descriptions used in application selection are
specified in the table below. For detailed descriptions on the data elements and
usage, please refer to Appendix A Card and Issuer Data Element List.
Table 4: Application Selection - Card Data
Data Element Description
AID consists of the registered application provider identifier

(RID) and Proprietary Application Identifier Extension (PIX).
It identifies the application described in ISO/IEC 7816-5.
Application Identifier (AID) If a card has more than one application with the same AID, the
card must have a suffix. If only one Application has the AID,
the card AID must not have suffix, unless another application
with the same AID is added to the card after personalization.
PSE starts from the DDF named “1PAY.SYS.DDF01”.

Payment System
Directory file related to the DDF is named Payment system
Environment (PSE)
directory.
DDF defines the files under its directory structure. FCI of DDF
includes:
FCI template
DF name
Directory Definition File
(DDF) FCI Proprietary template
Short File Identifier (SFI) of directory files
FCI issuer Discretionary data (optional)
UPI Confidential 12
It is the entry file of Application Elementary File (AEF).

Application Elementary File (AEF) includes the following
Application data elements:
FCI template
DF NAME
FCI Proprietary template
Application tag
Application priority indicator (conditional.

If a card has several payment accounts,
the priority of the account in the magnetic
Application Definition File stripe should be 1)
(ADF)
PDOL (optional)
Language priority (optional)
Issuer code table index (optional, if

Application preferred name exists)
Application preferred name (optional)
FCI issuer discretionary data (optional). If

the card supports logs, data element at the
log entry (9F4D) shall be included in the
issuer discretionary data.
Application Elementary File Application Elementary File includes the data elements used
(AEF) by the application in processing.
It is a file that specifies DDFs and ADFs under the Directory.

Directory file After selection, READ RECORD command can be applied to
access the file.
Payment system directory attached to the PSE DDF contains

Payment system directory entries for ADFs. Refer to the table 46 and table 47 for the
entry format.
File Control Information It is the Response information of SELECT command. For

(FCI) different types of files, the Response information may vary.
UPI Confidential 13
Short File Identifier is the pointer of Elementary File.
1-10 EMV reserved for future use

Short File Identifier (SFI)
11-20 Payment system specific
21-30 Issuer specific
It is used for application selection. It is in FCI of ADF

Application tag
(optional) and at the directory entry of ADF (mandatory)
It indicates the priority of a certain application specified in the

Application priority indicator Directory and whether the priority can only be selected after
confirmation of the cardholder.
It is the terminal data object list required by the card during the
Processing Option Data
Application initialization procedure. The contents include tags
Object List (PDOL)
and length of the data objects.
According to ISO8859, the index specifies the code list applied

Issuer code table index
when the terminal displays the Application preferred name.
If Application preferred name exists and the terminal supports

issuer code table index entry, Application preferred name rather
than Application tag is displayed to the cardholder at the end of
Application preferred name Application selection.
Application preferred name shall be the same as Application

tag; or it can also be left to the client for customized
processing.
4.2 Terminal Data
Terminal data used for application selection is specified in the table below. For
detailed descriptions on terminal data, please refer to the Terminal Specification.
Table 5: Application Selection - Terminal Data
UPI Confidential 14
Data Element Descriptions
AID consists of registered application provider identifier (RID)

and Proprietary Application Identifier Extension (PIX). It
AID
identifies the application specified in ISO/IEC 7816-5. Please
refer to descriptions in Table .
Application selection It indicates whether partial selection is supported for the AID in
indicator the terminal
Terminal supported It is a table maintained by the terminal. It includes the

application list supported applications and their respective AIDs.
4.3 Command
SELECT
SELECT command is described in Appendix B in detail.
The terminal sends SELECT Command to the card to obtain the card supported
application information, which includes issuer parameters, such as application
priority, application name and language preference, etc. The Command can include
not only the Payment System Environment Directory name (used for Directory
selection method) and one Directory(DDF) name, but also a requested AID (used
for the List of AID method).
The P1 parameter in the Command indicates that the Application is selected by

name. The P2 parameter indicates that whether there is another application with the
same AID is requested when AID suffix is supported (when the card supports many
applications with the same AID).
Command can have the following SW1 and SW2 return codes:
 9000 – Successful return from SELECT ;
 6A82 - The card does not support Directory selection method (The Command
includes name of the Payment System Environment); the selected file is not
found or it is the last file while P2 parameter indicates that there is another
application with the same AID (The Command includes AID);
 6A81 - CARD is blocked or the Command is not supported;
 6283 - APPLICATION is blocked.
If the card includes a PDOL, the PDOL is included in the Response information of
SELECT command as one part of FCI. During the Application initialization
processing, the terminal will transmit the data specified in the PDOL to the card.
UPI Confidential 15
READ RECORD
READ RECORD command is described in Appendix B in detail.
When Directory selection Method is used, READ RECORD command is used to

read records in the Payment System Environment Directory. It is used only when
one ADF or DDF is selected. The Command includes Short File Identifier (SFI) of
the file to be read and the record number of the record in the file.
The card returns the requested record contents in the Response information. The
SW1 and SW2 response may have the following values:
 9000 – The Command is successfully performed;
 6A83 – The record number does not existing.
4.4 Establish Candidate Application List
The terminal can apply two methods to establish the application list supported by
both card and terminal.
 As directory selection method is mandatory for the terminal but optional for
the card, the terminal shall select this method as the first priority. The terminal
reads from the card the Payment System Environment file which specifies all
payment applications supported by the card. The terminal adds any
applications in both card list and terminal list on the candidate list.
 AID list selection method is mandatory to both the card and the terminal. The
terminal sends a SELECT command to the card for each application supported
by the terminal. If the card indicates that it supports the application in the
Response, the terminal adds the Application on the candidate list.
4.4.1 Directory Selection Method
From the standpoint of the card, Directory Selection Method processing includes
the following steps:
1. The card receives a SELECT command from the terminal, requesting to select
PSE (file name “1PAY.SYS.DDF01”).
 If the CARD is Blocked or SELECT command is not supported, the card

responds with SW1 SW2=“6A81”;
 If the card does not have PSE, the card responds SELECT command and
indicates that the file does not exist (SW1 SW2=“6A82”);
 If PSE is blocked, the card responds with “6283”;
 If PSE is present, the card responds with SW1 SW2 = “9000” and the FCI
for PSE.
UPI Confidential 16
2. If PSE is present, the card accepts the READ RECORD command from the
terminal indicating the Short File Identifier and record number. The card
responds to each READ Record command with the requested record and SW1
SW2=“9000”. If the requested record does not exist, the card returns SW1
SW2=“6A83”.
The steps performed by terminal are indicated in the figure below:
1. Read Record 1 from payment system directory;
2. Check whether AID of ADF Entry 1 or 2 matches with the AIDs of the
terminal, and add the application in the candidate list if they are matched;
3. Read Record 2 from Payment system directory;
4. Check whether AID of ADF Entry 3 matches the AID of the terminal, and add
the application in the candidate list if they are matched;
5. Complete candidate list when the card responds that the Payment system
directory has no other records.
PSE
Payment system
directory
Record 1 Record 2
ADF Entry 1 ADF Entry 2 DDF Entry 3
Figure 2: Example of Card Directory Structure
4.4.2 AID List Selection Method
From the standpoint of the card, AID list selection method includes the following
steps:
1. The card receives the SELECT command sent by the terminal, and the terminal
includes AID that the terminal supports the application list. The card checks
whether the card has any application whose AID matches (the AID length of
card can be longer than that of the terminal).
The examples of AID matching are displayed in the table below.
UPI Confidential 17
Table 6: Example of AID Matching
Card
Terminal AID Terminal Application Card AID
Application
UnionPay IC UnionPay IC
A0000003330101 A000000333010101
Debit/Credit debit
UnionPay IC UnionPay IC
A0000003330101 A000000333010102
Debit/Credit credit
 If the AID matches, the card responds to the SELECT command and
indicates that the card supports the application (SW1 SW2=“9000”);
 If the card cannot find the matched AID, it responds with SW1
SW2=“6A82” to indicate that that the application is not found;
 If the card is blocked or the card does not support SELECT command, the
card responds with SW1 SW2=“6A81” to indicate that the transaction
shall be terminated.
2. If the matched card AID is longer than the terminal AID, the card responds the
entire card AID in the response information to the terminal for SELECT
command.
 The card receives another SELECT command from the terminal.

Parameter P2 in this SELECT is set as “02”, which indicates that the card
shall select another application with the same AID.
 The card selects next application with this AID and provides the
application to the terminal in the SELECT command response.
 When the card has no more application with such AID, the card shall
respond with SW1 SW2 =“6A82” to indicate that all the matched
applications have been selected.
4.5 Application Identification and Selection
If the candidate list has no less than one application that is supported by both card
and terminal, the terminal and the cardholder shall determine which application
shall be selected. The terminal sends a SELECT command to the card, indicating
an application which is identified to perform the transaction. If the card agrees with
the selection, it responds with SW1 SW2 “9000”. If the application is blocked,
Card must return FCI and response code ‘6283’. ”.
UPI Confidential 18
4.6 Flow Chart
Terminal Card
Terminal Supports SELECT Command

Directory Selection? With PSE in Filename Card Blocked
Terminal
Terminates SW1/2-6A81 Y N
Transaction
SW1/2-6A82 N PSE on card?
N Y
PSE
SW1/2-6283 Y Blocked?
Terminal
Switches to list
Of AIDs method Requests Respond with
directory records FCI for PSE and N
specified by SFI SW1/2=9000
in FCI
Requested
READ RECORD command
Record found?
All directory
A Y Record SW1/2=6A83 N
Processed?
C
N
Increment
Any more Process entries Y
Record N entries In record
SW1/2=9000
Number by 1
Terminal
Next entry=
Supports Y ADF N C
Application?
N Y
Add to
Candidate list
A
C
Terminal
Determines
Application to use
Respond with
Request FCI for SELECT Command with
FCI for ADF &
Selected application AID of application to be used
SW1/2 =9000
application
initialization，please
refer to chapter 5
Figure 3: Application Selection under Directory Method
UPI Confidential 19
Terminal Card
Terminal goes through its

list of supported AIDs
SELECT Command More AIDs

With AID from terminal list On list
N
Card blocked Y
A
N
Terminal
P2=02 SW1/2=6A81
Terminals transaction
(select next)
Card AID
Application SW1/2=
(Dfname) matches Y N Add to Candidate List
blocked 9000
Terminal AID?
Y
Y
SW1/2=6283
N
SW1/2=6A82
Another
Application
Matching applcaiton Y Y SW1/2=6283
blocked
For this AID
Respond with
AID & SW1/2 Add to Candidate List
=9000
N SW1/2=6A82
A
Final Selection
Terminal
Determines
Application to use
Request FCI for

Respond with FCI for SELECT Command with AID for
Directory file for
ADF & SW1/2 =9000 application to be used
ADF
application
initialization，please
refer to chapter 5
Figure 4: Application Selection under AID List Selection Mode
4.7 Subsequent Related Processing
Application Initialization
The terminal sends GET PROCESSING OPTIONS command to the card. During
Application selection, the SELECT command Response information include PDOL,
GPO Command shall include the terminal data specified in PDOL, such as the
terminal data are required in the transaction log..
If some restrictive conditions do not allow the selected application to be initialized,

the terminal terminates the application and returns to the application selection
procedures for another application.
UPI Confidential 20
5 Application Initialization
In the application initialization processing, the terminal notifies the card to start a
transaction by sending the GET PROCESSING OPTIONS Command to the card.
In this Command, the terminal provides the card with data elements requested in
Processing Option Data Object List (PDOL). PDOL (a list of tags and length of
data elements) is the optional data elements to be requested by the card to the
terminal during application selection process.
The card will respond with Application Interchange Profile (AIP) and Application
File Locator (AFL) information in the GPO Command. AIP specifies the functions
to be performed during transaction process; AFL specifies the Short File Identifier
for data storage location to be read during transaction processing, record number
and the static signature data storage location required for offline data
authentication.
5.1 Card Data
Card data elements used for application initialization are listed in the table below.
Table 7: Application Initialization - Card Data
AFL indicates the file location and record scope of the

card data to be read when the terminal executes
transaction processing. For each file to be read, AFL
includes the following information:
 Byte 1 - Short File Identifier (numeric tag of a file);

Application File Locator (AFL)
 Byte 2 - first record number to be read ;
 Byte 3 – last record number to be read;
 Byte 4 – number of consecutive records stored for

offline data authentication. Byte 2 indicates the first
record number to be read.
AIP is a list indicating capability (SDA, standard DDA,

CDA, terminal risk management, cardholder
authentication and issuer authentication) of a card to
Application Interchange Profile support designated functions in the application.
(AIP)
AIP must be written into the card during card
personalization to indicate that the card support terminal
risk management and cardholder authentication.
UPI Confidential 21
Application transaction counter After application personalization, the card application

(ATC) transaction counter starts.
CVR is UnionPay IC dedicated data that indicates from

the perspective of card the offline processing results of the
Card Verification Results (CVR) current transaction and last transaction. The data is stored
in the card and forwarded online as part of the issuer
application data.
CID indicates the cryptogram type returned by the card

Cryptogram Information Data and follow-up processing actions required for the
(CID) terminal. CID shall be 0 during the application
initialization processing.
During the application initialization processing, the card

Processing Option Data Object requires the list of data element tag and length to be
List (PDOL) provided by the terminal when it processes the GPO
Command.
5.2 Terminal Data
Terminal data used for application initialization processing is specified in the table
below.
Table 8: Application Initialization - Terminal Data
Data element Description
Other data from the terminal as specified in PDOL, such

Other data defined in PDOL
as terminal data required in the transaction logs.
5.3 Command
GET PROCESSING OPTIONS
The terminal uses GET PROCESSING OPTIONS Command to inform the card
that the transaction begins.
The Command includes value part of terminal data element requested by the card in
PDOL. PDOL consists of optional data provided by the card during application
selection.
The card response data consists of AIP and AFL. AIP specifies the functions
performed during transaction processing; AFL specifies the Short File Identifier for
UPI Confidential 22
data storage to be read during transaction processing, record number, number of

records and the static signature data storage location required for offline data
authentication.
For command code, please refer to Appendix B.
5.4 Processing Flow
After receiving GET PROCESSING OPTIONS Command from the terminal, the
card will:
1. Perform discretionary restriction check if the card supports discretionary

restriction check and terminal data specified in PDOL are included in the GET
PROCESSING OPTIONS Command. If restriction check is not successfully
performed, the card will respond “application condition is not satisfied” (SW1
SW2=”6985”) to indicate that the terminal shall delete the current application
from the candidate list and return to the application selection step for another
application.
2. Determine the file and records to be read and file location to establish AFL.
And return different AFL and AIP based on different transaction situations.
3. Follow the steps blow if discretionary restriction check is successful :
a) Increment ATC by 1, if ATC reaches 65535, then the card will block the
application permanently.
b) Reset Cryptogram Information Data (CID) as 0;
c) Reset Card Verification Results (CVR) (excluding length indicator bit) as

0;
d) Return AIP and AFL to the GPO command.
The following figure indicates the flow chart of application initialization

processing.
UPI Confidential 23
Card Terminal
Card receives GPO command,

including terminal data
specified in PDOL
PDOL processing normal?

NO
Terminal deletes
YES Get Processing Options transaction from the
command, candidate list and
respond’6985' returns to step of
application selection
The card blocks the

ATC+1 and check application
whether ATC reaches YES permanently. GPO
65535 command response
6985
NO
Set CID as 00
Set Byte 2-4 of CID

as 00
Get Processing Options Terminal performs the

Card returns AFL command, respond AFL step of read
and AIP application data
Figure 5: Flow Chart of Application Initialization
5.5 Prior Related Processing
Application Selection
The card provides the PDOL (if any) to the terminal in FCI of SELECT command
Response.
Application Selection
UPI Confidential 24
If any regional restriction or any other restriction is effective, the transaction shall
return to the application selection stage. The application is deleted from the
candidate list and another application will be selected.
Read Application Data
The card returns AFL to the terminal together in the response to the GET
PROCESSING OPTIONS Command. The terminal uses AFL to determine the
application data to be read from the card and the data to be used for offline data
authentication.
Offline Data Authentication
The terminal uses AIP in the response to the GET PROCESSING OPTIONS
Command to determine the offline data authentication type to be supported by the
card.
Cardholder Verification
Command to determine whether cardholder verification is supported by the card or
not.
Online Processing
Command to determine whether issuer authentication is supported by the card or
not.
UPI Confidential 25
6 Read Application Data
In Read Application Data processing, the terminal reads the card data necessary to
process transactions and determines the data to be authenticated during SDA or
DDA.
6.1 Card Data
The table below specifies the data to be applied during read application data
processing and response from the card during the application initialization
processing.
Table 9: Read Application Data - Card Data
Data element Descriptions
In the application initialization processing, the data that the

card returns to the terminal includes a group of record
entries to be read. Each entry includes:
 Byte 1 - Short File Identifier (numeric tag of a file);
Application File Locator (AFL)  Byte 2 - first record number to be read ;
 Byte 3 – last record number to be read;
 Byte 4 – number of consecutive records stored for

offline data authentication. Byte 2 indicates the first
record number to be read.
The table below specifies the data while reading Application Elementary File
records from the card.
Table 10: Read Application Data - Card files
Data element Descriptions
AEF is a card data file, including the data used for

application processing. An AEF includes a series of records
Application Elementary File specified with record number. Each AEF is solely identified
(AEF) with SFI. The terminal uses READ RECORD command to
read the record contents. The Command includes SFI and
record number.
SFI solely represents Application Definition File. It is listed

Short File Identifier (SFI) in AFL. The Terminal can use it to identify the files to be
read.
UPI Confidential 26
6.2 Terminal Data
During this stage of read application data, the card does not use terminal data.
6.3 Command
READ RECORD
For command code of READ RECORD, please refer to Appendix B.
The received command to the card shall include Short File Identifier (SFI) of the
file to be read and record number of the record in the file
The response of the card shall include the requested record in the data file.
6.4 Processing Flow
The card receives the READ RECORD command from the terminal and returns the
record contents requested by the terminal. Each record specified in AFL is read
with one READ RECORD command.
The terminal sends READ RECORD commands consecutively until all records
specified in AFL are read.
Record data for offline data authentication adopts TLV encoding format with the
ID number of ‘70’.
For data read with READ RECORD command, please refer to Appendix A.2.
In the application initialization processing, the card returns AFL to the terminal,
indicating the data records to be requested by the terminal.
Offline Data Authentication
The terminal uses a static data list established during Read application data
processing to conduct SDA authentication or IC card public key authentication
during DDA.
UPI Confidential 27
7 Offline Data Authentication
Offline Data Authentication is the processing that the terminal authenticates the
data in the card using RSA public key technology. There are two types of offline
data authentication:
 Static Data Authentication (SDA)
 Dynamic Data Authentication (DDA)
SDA indicates that the terminal authenticates the static (constant) data in the card.
SDA can ensure that the data selected by the issuer will not be altered after card
personalization.
DDA includes two authentication modes: standard DDA and Combined

DDA/Application Cryptogram Generation (CDA). During DDA processing, the
terminal authenticates the static data in the card and the cryptogram generated by
the card with the transaction-unique data. DDA can ensure that the data selected by
the issuer will not be altered after card personalization; DDA can also prevent
counterfeit card (skimming).
The result of offline data authentication is one of the reference conditions for the
card and the terminal to determine transaction offline, online or decline. The online
authorization system may also refer to the offline data authentication results before
making the authentication response decision.
The terminal with offline capability must support offline data authentication, but it
is optional for the card.
7.1 Key and Certificate
Please refer to 5.1 Key and Certificate in the Security Specification for details.
7.2 Determining the Method of Offline Data Authentication
The terminal uses Application Interchange Profile (AIP) of the card and offline data
authentication supported by the terminal itself to determine whether SDA, DDA or
CDA shall be performed.
7.2.1 Card Data
The card data that the terminal uses to determine whether to perform SDA or DDA
is specified in the table below.
Table 11: Offline Data Authentication - Card Data
UPI Confidential 28
Including specific indicator that:
 The card supports Static Data Authentication

(SDA);
Application Interchange Profile (AIP)  The card supports Dynamic Data Authentication
(DDA);
 The card supports Combined Data

Authentication (CDA).
7.2.2 Processing
Only one type of offline data authentication will be performed for one transaction.
CDA is superior to DDA, while DDA is superior to SDA. If the card or the
terminal supports no offline data authentication, offline data authentication will not
be performed.
If the terminal determines that both the card and the terminal support CDA, CDA
shall be performed; otherwise, if both support DDA, DDA shall be performed;
otherwise, if both support SDA, then the SDA shall be performed.
Record data for offline data authentication adopts TLV encoding type marked with
‘70’. As for the two types of files whose SFI is within ‘1-10’ and ‘11-30’
respectively, data processing shall follow different procedures during offline data
authentication processing. For details, please refer to relevant definitions in
Security part of This Specification.
If the record data applied for offline data authentication does not adopt TLV
encoding format marked with ‘70’, the terminal will take that offline data
authentication has been executed but failed. The terminal will set the “Offline data
authentication execution” bit in TSI as 1, and set the corresponding “SDA
FAILURE” or “DDA FAILURE” or “CDA FAILURE” bit in TVR as 1.
7.3 Static Data Authentication (SDA)
During SDA, the terminal used RSA public key verification technology to validate
whether the key data in the card has not been altered since card personalization.
7.3.1 Card Data
Card data used by the terminal for SDA is specified in the table below.
Table 12: Card Data used in SDA
UPI Confidential 29
PKI together with issuer public key certificate is

CA public key index (PKI) provided by CA. It defines the CA public key of the
terminal to authenticate issuer public key certificate.
The certificate includes the issuer public key which is

Issuer public key certificate
signed with CA private key.
It is used in RSA Algorithm to restore issuer public

Issuer public key Exponent
key certificate. The value is 3 or 65537.
It is the part of issuer public key which is not included

Issuer public key remainder
in issuer public key certificate (if any).
Registered application identification RID together with CA public key index identifies the
(RID) part in AID public key of the terminal.
UPI Confidential 30
SAD is the signature that authenticates the card static

data. During card personalization stage, SAD is
signed with issuer private key and stored in the card.
The following data is recommended to generate the
signature:
Application Interchange Profile (AIP) (if DDA is

supported);
Application effective date;
Application expiry date;
Application primary account number;
Application primary account number sequence

number;
Signed Static Application Data (SAD) Application Usage Control (AUC);
Cardholder Verification Method (CVM) list;
Issuer Action Code —— Default;
Issuer Action Code —— Rejection;
Issuer Action Code —— Online;
Issuer country code (“5F28”).
If the signature data of an application is not unique,

the card must support several SAD. For example, the
card sets separate CVM list for domestic and
international transactions, and CVM list is signature
data. Then if the issued card has signature data
alteration capability, the card must support SAD
alteration capability.
If AIP needs also to be signed, SDA identification list

includes AIP tag. If DDA is supported, it is
SDA tag list
recommended AIP can be signed. Except for, any
other data tag is not allowed.
The table below specifies the card internal data related to SDA.
Table 13: Card Data Related to SDA
UPI Confidential 31
CVR includes an indicator bit that provides reference

for subsequent transactions. The indicator bit indicates
Card Verification Results (CVR)
during card action analysis the SDA FAILURE of the
last offline rejection transaction.
If SDA fails and offline transaction is rejected, the bit

shall be set during card action analysis. Based on the
SDA FAILURE indicator conditions of issuer authentication, the indicator bit
can be reset during the closing of the next online
transaction.
7.3.2 Terminal Data
During SDA, the card does not need terminal data.
7.3.3 Command
SDA process is not involved any commands.
7.3.4 Processing Flow
During SDA, the terminal uses RSA public key verification technology to restore
and validate issuer public key and to validate SAD from the card. For details,
please refer to 5.2 Static Data Authentication (SDA) in the Security Specification.
Descriptions are summarized as follows:
1. Retrieve CA public key
The terminal uses PKI and RID in the card to determine which CA public key shall
be applied.
2. Retrieve issuer public key
The terminal uses CA public key to unlock the issuer PK certificate in the card and
to restore the issuer public key in the certificate
3. Verify the Signed Static Application Data
a) To restore Hash result;
b) To calculate Hash value;
c) To compare Hash results.
If all the SDA procedures are completed successfully, it can be deem that SDA
succeeded.
UPI Confidential 32
7.4 Dynamic Data Authentication (DDA)
During DDA processing, the terminal uses RSA public key technology to
determine whether key data in the card has been altered or not since card
personalization and whether the card is a counterfeit card or not.
UnionPay supports two DDA types: standard DDA and CDA. Under these two
types, the terminal validates whether static data in the card is altered or not and
validates the dynamic cryptogram generated by a card. During standard DDA, the
card generates dynamic signature with dynamic data from the card, the terminal
and the transaction data when it responds to INTERNAL AUTHENTICATE
Command before it performs card action analysis. During CDA, the card generate
dynamic signature when it responds to GENERATE Application Cryptogram
Command. The signature includes Application Cryptogram, Cryptogram
Information Data and the dynamic data of the card, the terminal and the transaction
data used as similar to standard DDA.
7.4.1 Card Data
Except for SAD, all the data used during SDA is used in DDA. The table below
specifies the data only applicable for DDA.
Table 14: Offline Data Authentication - Card Data for DDA
DDOL is designated in INTERNAL AUTHENTICATE

Command. The card requests a list of tags and lengths of
Dynamic Data Authentication
the terminal data sent by the terminal to the card. DDOL
Data Object List (DDOL)
shall at least have the tag of terminal unpredictable data
(tag “9F37”).
IC card dynamic data is issuer-specified data elements,

which is to be included in the signed dynamic application
IC card dynamic data
data. As specified in UnionPay: Byte 1 is the length of IC
card dynamic number; Byte 2 and 3 is ATC.
It is a part of IC card dynamic data. It contains time-variant

IC card dynamic numbers number generated by the IC card. It is recommended to be
ATC.
It contains the IC card public key signed with issuer private

key. It is stored in the card during card personalization. The
IC card public key certificate
certificate includes static application data signed with
issuer private key for encryption.
UPI Confidential 33
It is used to restore signed dynamic application data. The

IC card public key exponent
value is 3 or 65537.
It is part of the IC card public key which is not included in

IC card public key remainder
IC card public key certificate (if any).
It is the signature generated by the card when it receives

Signed dynamic application data
INTERNAL AUTHENTICATION Command.
The following table specifies the data elements used inside the card during DDA.
Table 15: Offline Data Authentication - Card Internal Data Elements for DDA
CVR includes the following indicator related to DDA:
Card Verification Results (CVR) Offline dynamic data authentication for the last transaction
fails, and offline data authentication for the offline declined
transaction is executed.
It is the private key used to sign dynamic application data

IC card private key
for encryption.
It indicates DDA failure the last offline rejection

transaction. Based on the conditions of issuer
DDA FAILURE indicator
authentication, the indicator can be reset during the step of
transaction closing of the next online transaction.
7.4.2 Terminal Data
The table below lists the terminal data applied by the card during DDA.
Table 16: Offline Data Authentication - Terminal Data
Unpredictable number and other It means the data in INTERNAL AUTHENTICATE

data elements specified in DDOL Command.
UPI Confidential 34
If the card does not have DDOL, default DDOL in the

Default DDOL
terminal shall be used
7.4.3 Command
7.4.3.1 INTERNAL AUTHENTICATE Command
During standard DDA, the terminal sends INTERNAL AUTHENTICATE

command which includes the terminal dynamic data specified in DDOL or default
DDOL.
In order to ensure that the response data of INTERNAL AUTHENTICATE

command is within 256 bytes, the length of both signed dynamic application data
and the optional TLV format code shall be restricted to the scope defined in
security part of this specification.
When the card receives INTERNAL AUTHENTICATE Command, it applies the

IC card private key to generate signed dynamic application data. The response data
to INTERNAL AUTHENTICATE Command includes the dynamic signature.
For the detail command code format, please refer to Appendix B.
7.4.3.2 GENERATE APPLICATION CRYPTORAM (AC) Command
The terminal sends the first GENERATE AC Command during card action analysis
processing. When either of the following condition is satisfied, the transaction shall
perform CDA:
When Bit 5 of P1 in the generating application cryptogram command is 1, it

indicates that the terminal requests to perform CDA and the AIP data in the card
indicates CDA is supported, when the card returns TC or ARQC, the TC or ARQC
shall be included in the DDA cryptogram. For detail description, please refer to the
part of the Security Specification.
For the detail command code format, please refer to Appendix B.
7.4.4 Processing
During DDA processing, the terminal uses RSA public key technology to validate
the issuer public key certificate, the IC card public key certificate and the signed
dynamic application data (dynamic signature) in the card.
During DDA processing, the only process of the card is to generate the dynamic
signature.
For detailed descriptions on DDA, please refer to 5.3 Dynamic Data Authentication
(DDA) in Security Specification. The following part is a summary.
UPI Confidential 35
7.4.4.1 Standard Dynamic Data Authentication (DDA)
Standard DDA processing consists of the following steps:
1. Retrieve CA public key
The terminal applies PKI and RID in the card to determine which CA public key
shall be applied.
2. Restore issuer public key
The terminal applies CA public key to unlock the issuer PK certificate in the card
and to restore issuer public key in the certificate.
3. Restore IC card public key
The terminal uses the issuer public key to unlock the IC card public key certificate
in the card and to authenticate the IC card public key and static data Hash result in
the card. IC card public key certificate ensures the validity of IC card public key.
The terminal uses the actual data elements in the card to re-calculate the Hash
values and to check whether the new Hash Value matches the restored Hash Value.
4. Generate dynamic signature (only for standard DDA)
The terminal sends INTERNAL AUTHENTICATE command to request for a

dynamic signature. The command includes the data requested by the card in
DDOL.
After it receives INTERNAL AUTHENTICATE Command, the card will:
a) Set the offline dynamic data authentication performed bit in CVR as “1”;
b) Concatenate terminal data in INTERNAL AUTHENTICATE command

and card data specified in IC card dynamic data. For detailed descriptions,
please refer to 5.3.5 Standard Dynamic Data Authentication in Security
Specification;
c) Generate a hash value from the data concatenated above;
d) Include the Hash values in the signed dynamic application data;
e) Use IC card private key to sign the signed dynamic application data;
f) Return the signed dynamic application data in the response of

INTERNAL AUTHENTICATE command.
5. Dynamic signature verification (only for standard DDA)
The terminal performs the following steps to validate the dynamic

signature:
a) Use IC card public key to decrypt dynamic signature and to restore data
element Hash Value;
UPI Confidential 36
b) Use dynamic data elements to re-calculate Hash values;
c) Compare two Hash values and verify if they match.
If all the procedures above are successful, then standard DDA can be considered as
successful.
7.4.4.2 Combined Dynamic Data Authentication / Application Cryptogram

Generation (CDA)
CDA processing consists of the following steps:
 The terminal performs Step 1 to 3 of standard DDA processing after it reads

the application data and before terminal action analysis starts.
 The remaining step for the card is to generate a dynamic signature that includes
Application Cryptogram. This step is performed when the card receives
GENERATE Application Cryptogram command. This can happen only when
the transaction complies with CDA execution conditions and Application
Cryptogram type is TC or ARQC.
 The remaining step for the terminal is to validate the dynamic signature
generated by the card. This step is performed during online processing. If the
validation fails, the transaction is declined.
The terminal reads data from the card. If the card supports SDA, the data shall
include the issuer public key certificate, other data related to the key and the signed
static authentication data (SAD). If the card supports DDA, the data shall include
DDOL, IC card public key certificate and other data related to key.
Terminal Action Analysis
The terminal uses the results of SDA or DDA as well as parameters of the card and
the terminal to determine whether the transaction is declined, sent online for
authorization or approved offline transaction.
Card Action Analysis
If the transaction is eligible for CDA, the card puts ARQC or TC in the signed
dynamic application data and uses IC card private key for signing before it
responds to the terminal.
If the indicator of Dynamic Data Authentication failure is “1”, the card sets the
Dynamic Data Authentication of the last transaction as failure in CVR and the
UPI Confidential 37
transaction rejection bit is “1”. If the indicator of Static Data Authentication failure
is “1”, the card sets a similar bit in CVR.
If the transaction is declined and the indicator for Dynamic Data Authentication
failure in the TVR sent by the terminal is “1”, the card sets the indicator of
Dynamic Data Authentication failure in the card as “1”. As for SDA, similar
processing shall be taken.
Online Processing
If CDA is performed and the Application Cryptogram returned by the card is

ARQC or TC, the terminal will restore and validate the signature data after the card
responds to GENERATE Application Cryptogram command.
Completion
When the transaction is processed online and issuer authentication is:
 Performed successfully;
 Supported as optional but not executed; or
 Not supported.
The indicator of Static Data Authentication failure and Dynamic Data

Authentication failure in the card can be set as “0”.
If the transaction is declined and the “CDA FAILURE” in TVR sent by the
terminal is “1”, the card sets indicators of Dynamic Data Authentication failure as
“1”.
UPI Confidential 38
8 Processing Restriction
The terminal uses data element from terminal and card to perform the Processing
Restriction such as checking the application version, the effective date, the
expiration date, and etc.
8.1 Card Data
The table below listed the card data elements used during Processing Restriction.
Table 17: Processing Restriction - Card Data
It refers to the date when application can be effectively

Application effective date
used.
It refers to the date when the application is no longer

Application expiration date
available for use.
The data element (card tag “9F08”) indicates the version of

Application version Number the application in the card. It is used when the terminal
performs application version check.
Optional data element. AUC indicates card application

Application Usage Control restrictions set by the issuer, including domestic,
(AUC) international, transaction type and the applied terminal
device, etc.
It is the data defined by EMV (5F28) which indicates the

Issuer country code country of the card issuer. It is applied when the terminal
performs Application Usage Control check.
8.2 Terminal Data
The table below lists the terminal data elements used during Processing Restriction.
Table 18: Processing Restriction - Terminal Data
The terminal tag “9F09” indicates the application version

Application version number
number of the terminal.
UPI Confidential 39
The data element indicates the financial transaction type. It

Terminal type is used when the terminal performs application Usage
Control check.
The data element indicates the country where the terminal is

Terminal country code located. It is applied when the terminal performs
Application Usage Control check.
It is the local date when transaction is taking place. It is

Terminal date used when the terminal executes the effective date and
expiration date check.
8.3 Processing
In Processing Restriction, the card does not perform any processing. The following
describes how the terminal uses card data during Processing Restriction.
8.3.1 Application Version Number Check
The terminal compares the application version numbers in the card and the
terminals to verify the consistency.
8.3.2 Application Usage Control check
During Application Usage Control, the terminal checks different situations of the
point of transaction to determine whether the transaction shall proceed. If the
terminal receives the Application Usage Control (AUC) and the issuer country code
data in the step of read application data, the terminal checks the following
application restrictions:
1. Domestic and International Check
Domestic
The terminal compares the issuer country code and the terminal country code. If
these two are consistent, the transaction can be taken as a domestic one and
therefore, the domestic indicator corresponding to Transaction Type in AUC must
be “1”, which indicates the requested service is allowed to be conducted.
For example: if it is a cash transaction, the “domestic cash transaction is valid”

indicator in AUC must be “1”.
International
If the country codes are different, the transaction shall be taken as an international
one, and therefore, the international indicator corresponding to Transaction Type in
UPI Confidential 40
AUC must be “1”, which indicates the requested services are allowed to be
conducted.
For example: if it is a cash transaction, the “international cash transaction is valid”

indicator bit in AUC must be “1”.
2. ATM Check
If the terminal device is ATM, the indicator for “Valid at ATM” in AUC must be
“1”. If the terminal device is not ATM, the indicator for “Valid at terminals other
than ATMs” bit in AUC must be “1”.
If any of the checks above performed by the terminal fails, the terminal will mark
in TVR that “the card product does not allow the requested service”.
The table below specifies the encoding format for AUC. If the indicator value is
“1”, it indicates that the usage is supported.
Table 19: Application Usage Control (AUC)
Byte b8 b7 b6 b5 b4 b3 b2 b1 Usage
1 1 x x x x x x x Domestic cash transaction is

valid.
1 x 1 x x x x x x International cash transaction

is valid.
1 x x 1 x x x x x Domestic commodity is valid.
International commodity is
1 x x x 1 x x x x
valid.
1 x x x x 1 x x x Domestic service is valid.
1 x x x x x 1 x x International service is valid.
1 x x x x x x 1 x ATM is valid.
Terminal (excluding ATM) is

1 x x x x x x x 1
valid.
UPI Confidential 41
Byte b8 b7 b6 b5 b4 b3 b2 b1 Usage
Domestic cash back is

2 1 x x x x x x x
allowed.
2 x 1 x x x x x x International cash back is

allowed.
8.3.3 Application Effective Date Check
When the card application data include application effective date, the terminal
performs application effective date check to ensure that the application is valid. If
application effective date is later than the transaction date, the terminal shall
indicate in TVR that the application is not effective yet.
8.3.4 Application Expiration Date Check
Application expiration date check is mandatory to ensure that the application is not
expired. If the application expiration date is earlier than the transaction date, the
terminal shall indicate in TVR that the application has been expired.
The terminal uses READ RECORD command to get record data from the card. The
data include issuer country code, application version number, application expiration
date, and if present, the AUC and application effective date.
At the terminal action analysis stage, the terminal checks Issuer Action Code (IAC)
and Terminal Action Code (TAC) to decide the transaction results.
UPI Confidential 42
9 Cardholder Verification
Cardholder verification is used to ensure that the cardholder is legitimate and the
card is not lost or stolen.
In cardholder verification processing, the terminal will determine the Cardholder

Verification Method (CVM) to be used and perform the selected cardholder
verification. CVM processing allows additional cardholder verification methods
such as biometric identification, etc. In case of offline PIN, the card shall verify
offline PIN in the card. Offline PIN verification results are included in the online
authorization information, and the issuer shall take the verification results into
consideration when it makes the authorization decision.
The terminal uses the rules in CVM list in the card to select the cardholder
verification method. The selection shall be based on the terminal type (cash or
purchase), transaction amount and terminal capability, etc. CVM list also indicates
to the terminal how to process in case of the CVM fails.
9.1 Card Data
The table below describes the card data used by the terminal during CVM list
processing.
Table 20: CVM List Processing - Card Data
The code is used to determine whether the transaction is in the

card’s currency. If the CVM List exists and the value for either
Application currency code
Amount X or Amount Y in CVM list is not zero, the
Application currency code shall exist.
Application Interchange AIP indicates whether the card supports cardholder

Profile (AIP) verification or not.
The list identifies a prioritized list of methods of cardholder

verification for the card application. A card shall have one
CVM List. In order to realize different application types, for
example, different verification methods are used in China and
abroad, the card shall have several CVM Lists. A CVM List
Cardholder verification includes the following contents:
method list (CVM List)
 Amount X
 Amount Y
 CVM entries - CVM List can have several entries and

each entry includes the following subfields:
UPI Confidential 43
Subfields Description
CVM code The code indicates when this CVM fails,

whether the next CVM shall be performed or to
regard CVM as failure.
CVM type CVM types include:
 Offline plaintext PIN verification
 Online encryption PIN verification
 Offline plaintext PIN verification plus

signature
 Signature
 CVM is not required (regarding that

CVM passes)
 CVM processing fails (regard that

CVM fails)
 Present certificate
CVM Conditions CVM conditions include:
 If CVM is always performed;
 If it is a cash or cash back transaction;
 If it is not a cash or cash back

transaction;
 If the terminal supports the CVM;
 If the transaction amount is less than

Amount X;
 If the transaction amount is more than

Amount X;
 If the transaction amount is less than

Amount Y;
 If the transaction amount is more than

Amount Y.
Note: the last four conditions require that the transaction

is in the card application currency
Below is an example on how an issuer defines CVM list:
Example
UPI Confidential 44
CVM List
An issuer may adopt the following modes to verify the cardholder:
 Online PIN for all ATM and cash back transactions,
 If the terminal supports offline PIN, offline PIN for POS transactions;
 If the terminal does not support offline PIN, signature for POS transactions;
 If the terminal supports offline PIN or signature, signature is not required for
POS transaction.
Refer to the table below for the contents of CVM List.
Table 21: Example of CVM List
Entry Value/meaning Remarks
Amount X 0 No amount check in CVM List
Amount Y 0 No amount check in CVM List
CVM entry 1
01- for cash or cash back

CVM condition
transactions
000010b-Online For ATM transactions, this CVM

CVM type encryption PIN entry shall be performed.
verification
0b- Cardholder
CVM code verification fails if CVM
fails
CVM entry 2
For POS transactions, this entry shall
03- if CVM supported by be performed
CVM condition
the terminal If the terminal supports offline
plaintext PIN verification, this CVM
000001b-Offline plaintext shall be performed
CVM type
PIN verification-
UPI Confidential 45
Entry Value/meaning Remarks
0b- Cardholder
fails
CVM entry 3
If the terminal does not support

03- if CVM supported by
CVM condition offline plaintext PIN verification,
the terminal
this CVM shall be performed
If the terminal supports signature

CVM type 011110b- signature
collection, this CVM shall be
performed
1b- Proceed to the next
CVM code
CVM if CVM fails
CVM entry 4
CVM condition 00- always

If the terminal does not support
offline PIN or signature, this CVM
011111b- CVM is not
CVM type shall be performed
required
CVM will never fail.
0b- Cardholder
fails
The table below describes the card data used by the card.
UPI Confidential 46
Table 22: Offline PIN Processing - Card Data
The maximum number of consecutive PIN errors as specified

PIN try limit
by the issuer.
The counter indicates the remaining PIN try times. The card uses
GET DATA command to return the PIN try counter (optional). The
counter is returned to the terminal during the verification
command.
When PIN verification fails, the counter shall be reduced by one

until the verification succeeds or the Script Command requesting
counter reset is released. Then the counter is reset at the maximum
PIN try counter
PIN try number. When the card supports offline PIN verification,
the counter shall be stored in the card.
This data is not necessarily readable. When the issuer wishes that
the terminal can obtain prompt information before the cardholder
inputs PIN for the last time, the data must be able to be read out
through GET DATA command; otherwise, the data shall not be
read by the terminal through GET DATA Command.
Offline PIN The card offline PIN is securely stored in the card.
CVR includes the indicator of the following items:
 Offline PIN verification performed;
Card Verification Results  Offline PIN verification fails;

(CVR)
 The PIN try limit have been exceeded;
 As PIN try limit have been exceeded, the application is

blocked.
Cardholder ID number The number is used for ID verification.
Cardholder ID type It is used to mark the ID type.
9.2 Terminal Data
The table below lists the data used by the terminal.
Table 23: PIN Processing - Terminal Data
UPI Confidential 47
Transaction PIN It is the PIN input by the cardholder.
9.3 Command
Offline PIN processing may use the following commands:
 GET DATA - The command is used by the terminal to obtain PIN try counter
value from the card. It is optional.
If the card does not support to return PIN try counter by GET DATA command, the
card will respond “6A88”.
 VERIFY - The command is used for offline plaintext PIN verification.
If the card supports offline PIN processing, it shall support VERIFY command.
Response status code SW1/2 of the command can have the following returned
values:
 “9000”, successful verification;
 “63Cx”, unmatched PIN, “x” indicates the remaining times;
 “6984”, if the try limit of the last transaction has been exceeded; this
value shall be returned when the VERIFY command is first processed
during this transaction.
 “6983”, the try limit of the transaction has been exceeded; this value shall
be returned when the card receives another VERIFY command.
9.4 Processing
The following describes the rules on dealing with different CVM types in the CVM
list.
9.4.1 CVM List Processing
Other than supplying the CVM list to the terminal during Read application data, the
card plays no role in CVM list processing.
9.4.2 Offline Plaintext PIN Processing
When a PIN is transmitted to the card, the card will:
1. Check PIN try counter
After the terminal decides to input an offline PIN, it can send a GET DATA
command to obtain PIN try counter value.
a) If the card supports returning the PIN try counter with GET DATA
command, the card will:
UPI Confidential 48
 Set the PIN try limit exceeded bit in CVR as “1” if PIN try
counter is “0”;
 Return the PIN try counter in the response of GET DATA

command to the terminal. If the counter is “0”, the terminal will
not allow the cardholder to enter offline PIN
b) If the card does not support returning the PIN try counter with GET
DATA command, the card will return “6A88”.
Terminal Card
Card supports
GET DATA command NO
PIN try counter response?
Mistaken
response to
YES GET DATA
command
PIN try counter = 0?
YES
Set PIN try limit excess bit in

CVR NO
Card puts PIN try counter

in the response information
GET DATA response Card returns the response
Figure 6: PIN Try Counter Check
2. Receiving VERIFY Command
After the cardholder enters the transaction PIN, the terminal sends a
VERIFY command that includes the transaction PIN entered. When the card
receives the VERIFY command, it shall set “offline PIN verification
performed” bit in CVR as “1”.
UPI Confidential 49
3. PIN verification
The card shall perform the following PIN verification steps:
a) When PIN try limit has been exceeded, the card will:
 Set the “PIN try limit exceeded” bit in CVR as “1”;
 Set the “offline PIN verification failure” bit in CVR as “1”;
 Return SW1/2=“6984” in the Verify response if PIN try limit is

exceeded in the previous transaction;
 Return SW1/2=“6983” in the Verify response if PIN try limit is

exceeded in the current transaction.
b) PIN matching
If PIN try function is not blocked, the card shall conduct PIN verification.
If the PIN matches, the card will:
 Set the PIN try counter at the maximum number (PIN try limit);
 Set the “offline PIN verification failure” bit in CVR as “0”;
 Return Response “9000” to VERIFY command.
c) PIN Unmatching
If transaction PIN does not match the offline PIN in the card, the card
will:
 Reduce PIN try counter by 1;
 Set the “offline PIN verification failure” bit in CVR as “1”.
 The card will judge whether the PIN try limit is exceeded or not.
 No more PIN try remaining
If the PIN try counter is “0”, the card will:
 Set the “PIN try limit exceeded” bit in CVR as “1”;
 Set “Application block due to PIN try times exceeded” bit in

CVR as “1” and block the application if there is Application
Default Action (ADA) data and “As PIN try limit is exceeded at
this transaction, the application is blocked” bit in ADA is “1”.
The card will allow the transaction to be performed until the
completion procedure. The APPLICATION BLOCK described
above will not cause permanent application or card invalidity.
 Returns Response “63C0” to VERIFY command.
UPI Confidential 50
 More PIN tries
If PIN try counter is not 0, the card returns “63Cx” to VERIFY

command in which x indicates the remaining try times.
Card
VERIFY PIN try limit
command NO
exceeded?
YES
Set offline PIN Transaction

Reduce PIN try
verification failure bit in PIN matches NO
counter by 1
CVR reference PIN?
YES Set “offline

Set PIN try limit excess” PIN verification
bit in CVR failure” bit in CVR
Reset PIN try counter
at the maximum value
PIN try limit

First verify Set offline PIN exceeded?
command in the verification failure bit
Terminal
transaction? in CVR as 0
YES
YES
NO PIN try limit
SW1 SW2 = 9000
exceeded?
NO
SW1 SW1
SW2=698 SW2=6
4 983
Application
block due to PIN
try limit excess” bit in
ADA set as 1?
SW1 SW2=63Cx YES
Set Application block

due to PIN try limit
excess bit in CVR NO
Set offline PIN verification
execution bit in CVR
Block Application
Return VERIFY
command with response
code
SW1 SW2=63C0
Figure 7: Offline Plaintext PIN Processing
4. Follow-up Processing
If PIN verification fails and there can be more PIN try times, the terminal will
prompt the cardholder to re-enter the transaction PIN and sends another VERIFY
command.
UPI Confidential 51
If PIN verification succeeds before the remaining try times are reduced to 0, the
card will:
 Reset the PIN try counter at the maximum number (PIN try limit);
 Set “offline PIN verification failure” bit in CVR as “0”.
The cardholder can enter incorrect PIN consecutively until the counter is zero.
Then the terminal will not send VERIFY command to the card.
9.4.3 Processing of Other CVMs
The card plays no role in the processing of online PIN or signature.
It shall be indicated in the Application Interchange Profile (AIP) included in the

response to GET PROCESSING OPTIONS command whether the card supports
cardholder verification or not.
The terminal reads the cardholder ID number, cardholder ID type, CVM list and
other card data required to process CVM List.
The terminal determines whether the transaction shall be declined, sent online for
authorization or approved offline based on the cardholder verification results and
parameters of the card and the terminal.
The card determines whether an advice shall be generated when PIN try limit is
exceeded based parameters in ADA.
The card determines whether the transaction shall be declined, or sent online for
authorization based on parameters in ADA when PIN try limit is exceeded during
the previous transactions.
Online Processing
CVM results include offline PIN verification results. The data is included in the
authorization request. The issuer shall consider the offline PIN verification results
when it makes authorization decision.
If CVM adopts online PIN, online request shall include the encrypted online PIN; if
CVM adopts offline PIN, online authorization request does not include the PIN
value.
UPI Confidential 52
Completion
If the terminal tries to perform online authorization for a transaction when PIN try
limit is exceeded, but fails, the card will determine whether the transaction shall be
declined or approved based on parameters of ADA.
Issuer-to-Card Script Processing
The PIN CHANGE / UNBLOCK Command can be used to reset PIN try counter at
the maximum number (PIN try limit), and change the offline PIN value in the card.
APPLICATION UNBLOCK command can be used to unblock the applications

blocked during CVM processing.
UPI Confidential 53
10 Terminal Risk Management
Terminal Risk Management provides issuer authorization for large amount

transactions. It can help that Chip-read transactions initiated from the cards go
online periodically to protect against credit and fraud risks that might be
undetectable in an offline environment.
The issuer shall support Terminal Risk Management. The terminal also needs to
support terminal risk management no matter whether the card supports terminal
risk management or not.
10.1 Card Data
The table below specifies the card data used by the terminal during Terminal Risk
Management:
Table 24: Terminal Risk Management - Card Data
Application primary account

It is the cardholder’s account number for the application.
number (PAN)
The counter is initialized when the card establishes the

Application Transaction Counter
application. The counter is maintained by the application
(ATC)
on the card.
It is the ATC value when the last online authorization

succeeds.
If the card requires issuer authentication as mandatory, at

Last online Application Transaction the processing completion stage, when issuer
(ATC) Register authentication is executed successfully, the value will be
reset.
The register is used for terminal risk management and

new card check.
It is the maximum times of Consecutive offline

Lower Consecutive Offline limit transactions as designated by the issuer and allowed by
“9F14” the terminal with online capability. It is used in the
terminal velocity check and new card check.
UPI Confidential 54
It is the limit of consecutive offline transactions as

designated by the issuer and allowed by the terminal. If
Upper Consecutive Offline limit
online authorization is not executed, the transaction will
“9F23”
be rejected. It is used in the terminal velocity check and
new card check.
10.2 Terminal Data
The table below specifies the terminal data used in terminal risk management.
Table 25: Terminal Risk Management - Terminal Data
The numeric data element (tag “9F02”) to store the

Authorized amount amount (Excluding adjustment) for the current
transaction. It is used in floor limit check.
Maximum target percentage to be

It is the data for random selection of online transaction.
used for biased random selection
Target percentage to be used for

It is the data for random selection of online transaction.
random selection
It is the floor limit for the application. It is used for floor

Terminal floor limit limit check and random selection of transaction online
processing.
Terminal Verification Results It is a set of indicators used to record all the processing
(TVR) results of terminal risk management.
Threshold value for biased random

It is the data for random selection of transaction online.
selection
UPI Confidential 55
It is the log of transactions that are stored in and accepted

by the terminal. It is used to prevent the cardholder from
avoiding floor limit check through installment
consumption. The log includes at least Primary Account
Number and transaction amount of the application, and
Transaction log
optionally sequence number of Application Primary
Account Number and the transaction date. The storage of
transaction quantity and maintenance of logs will be
defined based on concrete application. If the log exists, it
can be used in the terminal floor limit check.
It summarizes the functions performed by the terminal

during the transaction. The data element is not provided
Transaction Status Information
in online authorization and clearing message. But the
(TSI)
terminal uses this data element to indicate that terminal
risk management has been performed.
10.3 Command
GET DATA Command
If the value of last online Application Transaction Counter (ATC) and the value of
Application Transaction Counter do not exist in the terminal, the terminal sends a
GET DATA command to the card to read Register for last online Application
Transaction Counter (ATC) and Application Transaction Counter (ATC). The data
is used during terminal velocity check and new card check.
If the card supports terminal velocity check or new card check, it shall return the
data to the terminal.
If the card does not support terminal velocity check or new card check, the data
shall be stored as UnionPay dedicated data elements and shall not be returned to the
terminal. Then the card responds SW1 SW2=“6A88”.
For details of GET DATA Command, please refer to Appendix B.
10.4 Processing
During terminal velocity check and new card check, the card performs no
processing except for responding to GET DATA Command.
The following describes how the terminal uses card data during terminal risk
management:
UPI Confidential 56
10.4.1 Terminal Exception File Check
If there is terminal Exception file, the terminal shall check whether the application
primary account number (PAN) of the card is included or not.
10.4.2 Merchant Forced Transaction Online
Only on the terminal with online capability, can the merchant require the terminal
to perform online transaction. Card data is not needed during this step.
10.4.3 Floor Limit Check
Floor Limit check is performed when the transaction amount exceeds the terminal
floor limit, the transaction is forwarded online. Card data is not needed during this
step.
10.4.4 Random Transaction Selection
The terminal with offline and online capability shall perform random selection of
online transaction processing. Card data is not needed during this step.
10.4.5 Terminal Velocity Check
After consecutive offline transactions reach a certain times, Velocity check allows
the issuer to request online transaction processing. The issuer can select not to
support terminal Velocity check, then the upper and lower limit of consecutive
offline transaction (tag “9F14” and tag “9F23”) will not be written into the card
during personalization,.
During consecutive check, the terminal sends GET DATA Command to read the
value of last online ATC register and the value of ATC from the card.
The card returns the data requested.
The times of consecutive offline transactions are the difference between ATC and
the last online ATC register.
Note: the card can perform similar processing during card action analysis.
10.4.6 New Card Check
If the terminal performs new card check, the terminal checks whether the value of
the last online ATC register is zero or not (if any).
The terminal sends GET DATA Command to read the value of the last online ATC
register from the card.
Note: the card can perform similar processing during card action analysis.
The following data is read from the card:
UPI Confidential 57
 Application primary account number which is used for terminal exception file
check;
 Upper/lower limit for consecutive offline transaction which is used for terminal
velocity check (optional).
The terminal will make corresponding processing decision based on the setting of
the card and the terminal in case any of the following circumstance occurs.
 The card is included in the terminal exception file;
 The merchant requires mandatory online transaction;
 The lower limit is exceeded;
 The transaction is randomly selected as online transaction;
 The amount or counter exceeds relevant limit as detected during velocity

check;
 The card is a new one.
UPI Confidential 58
11 Terminal Action Analysis
During Terminal Action Analysis, the terminal will determine whether the
transaction shall be approved, declined or sent for online authorization based on the
offline processing results with the rules set by the issuer in the card and the rules
set by the payment system in the terminal. Terminal Action Analysis consists of the
following two steps:
1. Check offline processing results —— the terminal decides whether the

transaction shall be sent for online authorization, approved offline or declined
through checking the offline processing results. During the processing, Issuer
Action Code (IAC) defined in the card by the issuer and Terminal Action Code
(TAC) defined in the terminal shall be considered.
2. Request Cryptogram —— the terminal requests a cryptogram from the card.
During Terminal Action Analysis, the decision of transaction online or offline

approval is not the final result. During card action analysis, the card may
override the terminal’s decision. However, the card cannot override the
transaction decline decision made by the terminal.
11.1 Card Data
The following specifies the card data used by the terminal during terminal action
analysis.
Table 26: Terminal action analysis - Card Data
IAC consists of three data elements. Each is corresponding

to one bit of Terminal Verification Results (TVR). The three
Card Action Codes are:
IAC-denial
If the conditions in corresponding TVR are satisfied, the

transaction is rejected.
Card Action Code (IAC) IAC-online
If the conditions in corresponding TVR are satisfied, the

transaction is sent for online.
IAC-default
When online transaction is requested but it cannot be

performed, if the conditions in corresponding TVR are
satisfied, the transaction is declined.
UPI Confidential 59
It is suggested that IAC data should be used as the data for static offline data
authentication.
The table below specifies the data obtained by the terminal from previous steps for
cryptogram request.
Table 27: Request Cryptogram Processing - Card Data
The list specifies the tag and length of data to be

Card Risk Management Data
provided by the terminal so that the card can
Object List 1 (CDOL1)
GENERATE Application Cryptogram.
The list specifies the data objects (tag and length)

Transaction Certificate Data
required for Hash calculation to generate Transaction
Object List (TDOL)
Certificate (TC).
11.2 Terminal Data
The following specifies the terminal data used by the terminal during Terminal
Action Analysis.
Table 28: Offline Processing Result Check - Terminal Data
TAC consists of 3 data elements. Each has a serial of

bits corresponding to the data bits in TVR. The three
data elements are respectively:
 TAC-denial
The acquirer sets the TVR condition bit that can cause
offline decline.
Terminal Action Code (TACs)  TAC-online
online transaction.
 TAC-default
offline rejection when online transaction cannot be
performed.
The table below lists the terminal data elements used by the terminal when it
requests Application Cryptogram.
UPI Confidential 60
Table 29: Request Cryptogram Processing - Terminal Data
The data element refers to the terminal data designated

Terminal data element in CDOL1 or TDOL. It is used in data GENERATE
Application Cryptogram Command.
Transaction Certificate (TC) Hash The data element is optional. It is transmitted to the card
result through GENERATE AC Command as input data.
11.3 Command
GENERATE Application Cryptogram (AC)
The terminal uses GENERATE AC Command to request the card to generate an

Application Cryptogram.
Parameter P1 in the Command indicates the cryptogram type being requested and
whether the cryptogram is eligible for CDA. Data part in the command includes
terminal data elements requested by the card in CDOL1. CDOL1 is read by the
terminal from the card during read application data processing. When CDOL1
includes terminal capability data tag, and both the terminal capability data value
from the terminal and AIP in the card indicate that both the card and the terminal
support CDA, CDA will be performed.
The card processes GENERATE AC Command and makes response.
For details of command encoding, please refer to Appendix B.
11.4 Processing
11.4.1 Offline Processing Result Check
Offline processing result check is performed by the terminal during terminal action
analysis using IAC from the card and TAC from the terminal.
The card has no processing in this step.
11.4.2 Cryptogram Request
During cryptogram request, the terminal sends a GENERATE AC Command to the

card to request an Application Cryptogram. The command includes the terminal
data elements designated in CDOL1.
After the card receives the Command, the card performs card action analysis
processing. (Next chapter: Card Action Analysis).
UPI Confidential 61
During read application data processing, the card returns the application data
records to the terminal, including IAC, CDOL1, etc.
During card action analysis, the card performs risk management to determine
whether the terminal can make transaction declined, approved offline or sent for
online authorization.
UPI Confidential 62
12 Card Action Analysis
Card Action Analysis allows the Velocity check and other risk management check
set by the issuer in the card. This section describes the UnionPay defined card risk
management including the following checks:
 The previous transaction behavior;
 Whether the card is a new one;
 Offline transaction counters and amount accumulators
After completing Card Risk Management, the card returns an Application

Cryptogram to the terminal. This cryptogram is an AAC for an offline decline, an
ARQC for a request for an online authorization request, and a TC for an offline
approval. If supported by both card and terminal, the terminal may request CDA
where the card returns an ARQC or TC as part of a dynamic signature.
12.1 Card Data
The table below lists the card data used during Card Action Analysis processing.
Table 30: Card Action Analysis - Card Data
A cryptogram returned by the card in the Response for

GENERATE Application Cryptogram(AC) Command:
 An Application Authentication Cryptogram (AAC) for

Application Cryptogram offline decline;
 A Transaction Certificate (TC) for offline approval;
 An Authorization Request Cryptogram (ARQC) when

online processing is requested
The element indicates the domestic currency related to the

Application currency code
application. It is the currency designated by the card.
It is the indicator defined by the issuer. ADA indicates the

Application Default Action
card actions under certain special conditions. If the card does
(ADA)
not include ADA, it will be taken as 0.
Application Interchange Profile AIP includes the indicator that describes the capability of
(AIP) the card to support CDA and issuer authentication
UPI Confidential 63
It is included in the first GENERATE Application

Cryptogram Command sent by the card to the terminal
requesting for the data object (tag and length). The following
data in CDOL1 is applied in card risk management check:
 Transaction currency code – Velocity checking for total

consecutive offline international transactions (based on
currency), Velocity checking for total amount in
designated currency, and velocity check for total
transaction amount (Dual currency)
Object List 1 (CDOL1)  Terminal country code - velocity check (country based)
on consecutive international offline transaction times;
 Authorized amount - velocity check on accumulated

offline transaction amount in local currency, and
velocity check on accumulated offline transaction
amount (Dual currency);
 Terminal Verification Results (TVR) – including

indicator representing failure of SDA and DDA.
Data in CDOL1 shall not be repeated.
UnionPay dedicated data. It represents the offline processing

results of the current and the previous transactions. The data
will be transmitted online as part of the issuer application
data.
CID is returned to the terminal in the GENERATE AC

Cryptogram Information Data response. It indicates the type of cryptogram being returned
(CID) by the card. CID also includes the indicator whether advice
shall be generated and the reason code for advice generation.
UnionPay dedicated data. For each application of offline

Consecutive offline transaction
transaction in currencies not designated by the card, the
counter (international-currency)
counter shall be added by 1.
UnionPay dedicated data. It is the limit on offline transactions

in currencies not designated by the card. If the limit is
limit (international-currency)
exceeded, online processing shall be requested.
UnionPay dedicated data. For each offline transaction whose

issuer country code differs from terminal country code, the
counter (international-country)
counter shall be added by 1.
UPI Confidential 64
UnionPay dedicated data. It is the limit on offline transactions

consecutive offline transaction whose issuer country code differs from terminal country
limit (international-country) code. If the limit is exceeded, online processing shall be
requested.
UnionPay dedicated data. It is recorded the total amount of

Accumulated offline transaction
offline transactions in currencies designated by the card ever
amount
since last online processing.
UnionPay dedicated data. It is the limit on accumulated

offline transaction amount. If it is exceeded, online
amount limit
processing shall be requested.
UnionPay dedicated data. It is recorded the total amount of

offline transactions in currencies designated by the card and a
amount (dual currencies)
second currency ever since the last online processing.
UnionPay dedicated data. It is the limit on accumulated

offline transaction amount (double currencies). If it is
amount limit (dual currencies)
exceeded, online processing shall be requested.
It is the exchange rate when the second application currency

is converted to the currency designated by the application.
Currency conversion factor The data element has four bytes. The first high nibble
indicates location of the decimal, while the remaining seven
nibbles indicate the exchange rate value.
It is the card internal application indicator when DDA of the

DDA FAILURE indicator
last transaction fails and the transaction is declined.
It is the card internal application indicator when any of the

following two circumstances happens to the last online
Issuer authentication failure transaction:
indicator
 Issuer authentication is performed unsuccessfully;
 Issuer authentication is mandatory but not performed.
It indicates whether the issuer authentication supported by the

Issuer authentication indicator
card is mandatory or optional.
UPI Confidential 65
Issuer country code (“9F57”) UnionPay dedicated data. It indicates country of the issuer.
It is recorded the quantity of issuer Script Commands with

Issuer Script Command counter
Secure Messaging during the last online transaction.
The indicator is set when issuer script processing fails during

Issuer Script failure indicator
the last online transaction.
UnionPay dedicated data. It is the maximum limit on

Lower limit of consecutive offline
consecutive offline transactions allowed by the card before
transaction (“9F58”)
applying for online authorization.
Offline decline requested by the It is the card internal application indicator when transaction
card indicator decline is decided in the card risk management check.
It is the internal application indicator when the transaction

Online authorization indicator applying for online cannot get online or online authorization
is suspended.
It is the card internal application indicator when card risk

Card online request indicator
management check decides to send for online authorization
PIN try times counter It records the remaining PIN try times.
It is used for velocity check on dual currencies. It can be

Second application currency code converted to local currency (card designated currency) with
the currency conversion factor.
It is the card internal application indicator when SDA of the

SDA failure indicator
last transaction fails and the transaction is rejected.
After the card makes the transaction acceptance decision, the

Transaction Details Short File
card automatically records the transaction details. Short File
Identifier
Identifier of transaction details files identifies the file.
12.2 Terminal Data
The table below specifies the terminal data used during Card Risk Management.
UPI Confidential 66
Table31: Card Action analysis - Terminal Data
Data element Description
Authorized amount Amount of the transaction
It indicates the currency of the transaction. It is requested by

Transaction currency code
the card in the CDOL1.
It indicates the country of the terminal. It is requested by the

Terminal country code
card in the CDOL1.
Terminal Validation Results It is a series of indicators at the terminal that records offline
(TVR) processing results.
12.3 Command
GENERATE Application Cryptogram Command
The terminal uses GENERATE Application Cryptogram Command to request the

card for an Application Cryptogram indicating the card’s authorization response
Parameter P1 in the Command indicates the cryptogram type and whether CDA
needs to be performed. Data part of the Command includes the terminal data
requested in the CDOL1.
Response information of the Command includes Application Cryptogram and

Cryptogram Information Data. If the card performs CDA and the cryptogram type
is ARQC or TC, cryptogram shall use IC card private key to be signed as the signed
dynamic application data. For detailed descriptions, please refer to offline data
authentication part in the Security Specification.
12.4 Processing
12.4.1 Card Receives Cryptogram Request
The card receives GENERATE AC Command from the terminal. Data part of the
command includes the terminal data requested by the card in the CDOL1. If both
CDOL1 and PDOL contain a tag (the tag includes but not limited to transaction
currency code '5F2A' and authorized amount '9F02', but excludes terminal
verification result '95', transaction status information '9B' and unpredictable number
'9F37'), while the value of the tag given by the terminal in the GENERATE AC
Command is inconsistent with the value of the tag from the GPO Command, the
card should read the value received from the GENERATE AC Command, and the
value should be used in all subsequent processes of the transaction. The card should
not give a non-9000 response to GENERATE AC Command due to inconsistency
UPI Confidential 67
of the tag value from the GENERATE AC Command with the tag value from the
GPO Command.
Table 32 lists the data required for supporting card risk management as indicated in
CDOL1.
12.4.2 Card Risk Management
The table below summarizes all card risk management checks, indicates which are
mandatory or optional and specifies the results.
If the issuer selects to perform any optional card risk management check, it needs
to ensure that the data for check is written into the card during card personalization
and that CDOL1 specifies tag and length of the terminal data required.
If the requested terminal data is not valid (i.e. data part in GENERATE AC
Command uses 0 for relevant bits), the card will skip to the next card risk
management check. If the card has no Application Default Action (ADA), the card
will use a default value of all zero.
Table 32: Card Risk Management Check
Results (if conditions

Risk Management Check Requirement
satisfied)
Conditional – required if
Online authorization not
issuer Script Command or Request online processing,
completed (on previous
issuer authentication is and set CVR indicator
transaction)
supported
Issuer authentication failure Set CVR indicator

on last transaction (or issuer Conditional – required if
authentication is mandatory issuer authentication is Check ADA, and request
but not performed during last supported online processing if it is
transaction) indicated.
Conditional – required if
SDA failed on last transaction Set CVR indicator
SDA is supported
DDA failed on last Conditional – required if

Set CVR indicator
transaction DDA is supported
UPI Confidential 68

satisfied)
Provide the number of Script

Commands processed in
CVR.
Conditional – required if Set CVR indicator if script

Issuer script processed on last processing failed (using
post-issuance updates is
online transaction issuer Script failure indicator
supported
in the card). Setting in ADA
decides whether the
transaction shall result in
online processing.
Velocity check on lower limit Request online processing if

of consecutive offline Optional the limit is exceeded.
transactions Set indicator in CVR.
Velocity check on Request online processing if

consecutive international the limit is exceeded.
Optional
offline transactions (currency
based) Set indicator in CVR.
Velocity check on Request online processing if

consecutive international the limit is exceeded.
Optional
offline transactions (country
based) Set indicator bit in CVR.
Velocity check on
accumulated offline Request online processing if
transaction amount in Optional the limit is exceeded.
application designated Set indicator in CVR.
currency
Request online processing if

the limit is exceeded.
Velocity check on
Set indicator in CVR.
accumulated offline
Optional
transaction amount (double If the currency applied is a
currencies) second currency, currency
conversion shall be
performed at first.
UPI Confidential 69

satisfied)
Apply for online if there is no

New card check Optional such request before.
Set indicator in CVR.
Set the indicator in CVR if

offline PIN Verification for
the transaction is not
Offline PIN verification is performed and PIN try limit
not performed (PIN try limit Optional has been exceeded.
is exceeded)
Set transaction decline or
online request in ADA in
such circumstance.
12.4.3 Card Risk Management Process
The card performs each card risk management check to decide if the condition has
occurred, then proceeds to the next check. If there is any check that is not supported,
the card continues conducting to the next check.
12.4.3.1 “Online Authorization Not Completed” Check
If issuer authentication or issuer Script Command is supported, this check shall be

performed. The aim is to check during the last transaction whether the card was
moved from the terminal device after the card requests for an online authorization
and before the terminal receives online response for processing or before the
terminal makes any processing as it cannot get online. The online authorization
indicator in the card shall be set as “1” when online authorization is requested
during the last transaction.
If the indicator is set, the card will request for online processing until transaction is
sent online and one of the following conditions is satisfied:
 Issuer authentication is successfully completed;
 Issuer authentication is optional and has not been performed;
 Issuer authentication is not supported.
Note: this indicator is reset during completion based on issuer authentication status
and card parameters.
If online authorization indicator is set as “1”, the card will:
 Set card online request indicator as “1”;
UPI Confidential 70
 Set “last online transaction not completed” in CVR as “1”.
12.4.3.2 “Issuer Authentication Failed for the Last Transaction” Check (or
Mandatory but Not Performed)
If AIP in the card indicates that issuer authentication is supported, this check must
be performed. If issuer authentication for the last transaction (1) failed, or (2) is
mandatory (as indicated by the issuer authentication indicator) but not performed,
the card will request online processing.
If the issuer authentication failure indicator is set as “1”, the card will:
 Set “Issuer authentication for last online transaction failed” bit in CVR as “1”;
 If the ADA bit for Issuer Authentication Failure, Transmit Next Transaction
Online is “1”, Sets the internal online requested by card indicator as ‘1’.
12.4.3.3 “Static Data Authentication (SDA) Failed for Last Transaction”

Check
If SDA is supported, the check is mandatory to be performed to check whether

SDA failed for the last declined offline transaction.
If SDA failure indicator is set as “1”, the card sets “SDA for last transaction fails
and the transaction declined offline” in CVR as “1”.
12.4.3.4 “Dynamic Data Authentication (DDA) failed for last transaction”

check
If DDA is supported, the check is mandatory to be performed to check whether

DDA failed for the last declined offline transaction
If DDA failure indicator is set as “1”, the card sets “DDA for last transaction fails
and the transaction declined offline” in CVR as “1”.
12.4.3.5 “Issuer Script Processed for Last Online Transaction” Check
If issuer script processing is supported, the check is mandatory to be performed. It

provides the issuer with a count of number of Issuer Script Commands processed
on the last transaction and indicates whether script processing failed.
The card sets Bit 8-5 of the fourth Byte of the CVR to the value of the Issuer Script
Command Counter using identical bit settings.
If the issuer script failure indicator is set as “1”, the card sets the “Issuer script
processing failed for last transaction” bit in CVR as “1”.
If the issuer script failure indicator is set as “1”, the card shall set the online
requested by the card indicator bit as “1” when the ADA bit for “If issuer Script
for the last transaction fails, the transaction is forwarded online” is set as “1”.
12.4.3.6 Velocity Check on Lower Limit for Consecutive Offline Transactions
UPI Confidential 71
The check is optional. If the times of consecutive offline transactions exceed the
lower limit, the card will request for online authorization.
If the ATC register and UnionPay dedicated data for the last online transaction
have lower limit for consecutive offline transactions (tag “9F58”), the card can
perform the check.
If the difference between ATC and ATC register for the last online transaction is
larger than the lower limit for consecutive offline transaction, the card will:
 Set “Exceeded velocity check counters ”bit in CVR as “1”;
 Set the online requested by the card indicator as “1” to request that an ARQC
should be returned after card risk management is completed.
12.4.3.7 Velocity Check on limit for consecutive International Offline

Transactions (Currency Based)
This check is optional. If consecutive offline transaction counter

(international-currency) exceeds the consecutive offline transaction limit
(international-currency), the card will request for online authorization. International
offline transaction defined for the check is the one whose transaction currency code
from the terminal differs from the application currency code in the card.
If the application currency code, consecutive offline transaction counter

(international-currency) and consecutive offline transaction limit
(international-currency) do exist, the card shall perform this check.
The card compares the transaction currency code and the application currency code.
If they are different, and if the consecutive offline transaction counter
(international-currency) plus 1 is more than the consecutive offline transactions
limit (international-currency), the card will:
 Set “Exceeded velocity check counter” bit in CVR as “1”;
 Set the online requested by card indicator bit as “1”.
12.4.3.8 Velocity Check on Consecutive International Offline Transaction

Limit (Country Based)
The check is optional. If the consecutive offline transaction counter

(international-country) exceeds the consecutive offline transaction limit
(international-country), the card will request for online authorization. International
offline transaction defined for the check is the one whose terminal country code
from the terminal differs from the issuer country code in the card.
If the issuer country code, consecutive offline transaction counter

(international-country) and consecutive offline transaction limit
(international-country) exist, the card shall perform the check.
UPI Confidential 72
If the following two conditions are satisfied:
 Terminal country code differs from the issuer country code;
 The consecutive offline transaction counter (international-country) plus 1 is

more than the consecutive offline transaction limit (international-country).
The card will:
 Set “exceeded velocity check counter” bit in CVR as “1”;
12.4.3.9 Velocity Check on Accumulated Offline Transaction Amount in

Designated Currency
The check is optional. If the accumulated offline transaction amount in the

application designated currency exceeds the accumulated offline transaction
amount limit, the card will request for online authorization.
If the application currency code, accumulated offline transaction amount and

accumulated offline transaction amount limit exist, the card will perform the check.
If the following two conditions are satisfied:
 Transaction currency code equals to the application currency code;
 The sum of the accumulated offline transaction amount and the authorized
amount is more than the accumulated offline transaction amount limit.
The card will:
 Set “Exceeded Velocity check counter” bit in CVR as “1”;
12.4.3.10 Velocity Check on Accumulated Transaction Amount (Dual

Currencies)
The check is optional. If the limit on the amount accumulated for consecutive
offline approved transactions performed in the application designated currency or a
second designated application currency has been exceeded, the card will request for
If the application currency code, the second application currency code, the currency
conversion factor, the accumulated offline transaction amount (dual currency) and
the accumulated offline transaction amount limit (double currencies) exist, the card
will perform the check.
 If the transaction currency code equals to the application currency code, the
sum of the accumulated offline transaction amount (double currencies) and the
UPI Confidential 73
authorized amount shall be compared with the accumulated offline transaction

amount limit (dual currency).
 If the transaction currency code equals to the second application currency code,
the authorized amount shall be converted to the application currency code
amount at the currency conversion factor. The sum of the accumulated offline
transaction amount (double currencies) and the converted authorized amount
shall be compared with the accumulated offline transaction amount limit (dual
currency).
 If the comparison result is that the limit is exceeded, the card will:
 Set “Exceeded Velocity check counters” bit in CVR as “1”;
 Set the online requested by card indicator bit as “1”.
12.4.3.11 New Card check
The check is optional. If the card is a new one, the transaction requests for online
authorization. New card refers to the one which has not been approved online.
If the last online ATC register and Application Default Action exist, the card will
perform the check.
If the last online ATC register is zero, the card will:
 Set “New card” bit in CVR as “1”;
 Set the online requested by card indicator bit as “1” if “Online transaction for
new card” bit in ADA is “1”.
Note: if the card requests for mandatory execution of issuer authentication, the
ATC register value for the last online transaction shall always be zero unless the
issuer authentication is successful.
12.4.3.12 “Offline PIN Verification Not Performed (PIN Try Limit is

Exceeded)” check
When the card supports offline PIN verification, this check is optional. If PIN try
limit has been exceeded during the last transaction, the transaction will request for
online processing.
If the check is to be performed, the Application Default Action (ADA) data shall be
present in the card.
If all the following conditions are satisfied:
 The card supports offline PIN verification;
 A VERIFY Command was not received from the terminal
 PIN try times counter has become zero.
UPI Confidential 74
The card will perform the following actions:
 Set “PIN try limit exceeded” bit in CVR
 Set “Offline Decline requested by card indicator bit” as “1” if “PIN try limit
exceeded on previous transaction, Decline transaction” in ADA equals ‘1’
 Set online requested by card indicator bit as “1” if “PIN try limit exceeded on
previous transaction, go online” in ADA equals “1”
 Decline the transaction and block the application if “PIN try limit exceeded on
previous transaction, decline and block application” in ADA equals “1”
12.5 Card Provides Response Cryptogram
The card responds to the GENERATE AC Command from the terminal based on
results of card risk management. Response of the card may override the cryptogram
type specified by Parameter P1 in GENERATE AC Command from the terminal.
The change shall comply with the following rules:
 The card can override the decision of approve offline by the terminal to send
online or decline
 The card can override the decision of sent online by the terminal to decline.
The table below indicates the rules for change.
Table 33: Card Response to 1st GENERATE Application Cryptogram Command
Card response
AAC ARQC TC
AAC Decline - -
Terminal
ARQC Decline Go Online -
request
TC Decline Go Online Approve
If the offline decline requested by card indicator is “1”, it indicates that the card
decides to decline the transaction. If the online requested by card indicator is “1”, it
indicates that the card decides to send for online authorization.
The card sets the CVR to indicate that a TC (Offline approval), AAC (Offline
decline), or ARQC (go online for authorization) is to be returned in response to the
first GENERATE AC and that a second GENERATE AC has not been requested.
UPI Confidential 75
The card uses data provided by the terminal and data in the card to generate a
symmetric key algorithm based cryptogram. For detail data and algorithm required,
please refer to Appendix D.
12.5.1 Card Declined Transaction Offline
When the transaction is declined offline, the card uses AAC to respond to
GENERATE AC Command. But before that, the card will:
1. Check Application Default Action (ADA):
 If the ADA bit for If Transaction Declined Office, Create Advice = “1”,
set Advice Required to “1” in the Cryptogram Information Data (CID)
 If the PIN try limit is exceeded on this transaction and it is indicated in

ADA that an advice is required when this occurs:
 Set “Advice Required in CID” bit as “1”;
 If the reason code in CID is not “service is not allowed”, set it into
“PIN tries are exceeded”
Note: In CID, the reason code “service is not allowed” is much superior to others.
2. Check TVR provided by the terminal in GENERATE AC Command
 Set SDA Failure indicator in the card as “1” if SDA Failure bit is “1”;
 Set DDA Failure Indicator in the card as “1” if DDA Failure bit is “1” or
CDA Failure bit is “1”.
3. Add the counter by 1, if present, as follows:
 If the Terminal Country Code differs from the Issuer Country Code,
consecutive offline transaction counter (international-country) will be
increased by 1;
 If the Transaction Currency Code differs from the Application Currency

Code, Consecutive Offline Transaction Counter (international-currency)
will be increased by 1.
12.5.2 Card Requested for Online Processing
When the transaction is sent online for authorization, the card will use ARQC to
respond to GENERATE AC Command. Before responding, the card sets the Online
Authorization Indicator bit in the card as “1”.
Note: the following counters shall not be increased: Consecutive Offline

Transaction Counter (international - currency), Consecutive Offline Transaction
Counter (international-country), Accumulated Offline Transaction Amount and
Accumulated Offline Transaction Amount (dual currencies).
UPI Confidential 76
12.5.3 Card Approved Transaction Offline
When the transaction is to be approved offline, the card uses TC to respond to

GENERATE Application Cryptogram Command. Before responding, the card will
increase relevant counter by 1, if present, as follows:
 If the Terminal Country Code differs from the Issuer Country Code,
Consecutive Offline Transaction Counter (international-country) is increased
by 1;
 If the Transaction Currency Code equals to the Application Currency Code:
 Accumulated Offline Transaction Amount is accumulated with the

authorized amount;
 Accumulated Offline Transaction Amount (dual currencies) is

accumulated with the authorized amount.
 If the Transaction Currency Code differs from the Application Currency Code,
Consecutive Offline Transaction Counter (international-currency) is increased
by 1;
 If the Transaction Currency Code equals to the Second Application Currency

Code, authorized amount is converted to the amount in the application
designated currency with the currency conversion factor and the converted
authorized amount will be accumulated with the accumulated offline
transaction amount (dual currencies);
 The card records the transaction details. The detailed contents will be
transmitted to the card through GET PROCESSING OPTIONS Command
during transaction initialization. For card transaction details, please refer to
Chapter16.
12.5.4 Combined Dynamic Data Authentication Application Cryptogram

Generation Requested
When CDA of P1 in the generating application cryptogram command is 1, and

the AIP data in the card indicates CDA is supported, the card will perform CDA.
Card:
1. Perform standard Card Risk Management and generate Application

Cryptogram as described above;
2. Not perform special processing, return the AAC in the GENERATE AC

response if the card responds AAC;
3. If the card responds ARQC or TC, the Application Cryptogram responded by

the card will be signed with IC card private key as signed dynamic application
data. The detailed procedures are as follows:
UPI Confidential 77
a) Set the Offline DDA Performed bit to “1” in the CVR. This step shall be
executed prior to the generation of Application Cryptogram in Step 1
b) Use Application Cryptogram to generate a dynamic signature cryptogram.

For details, please refer to 5.3.6 in Security Specification. In summary,
this step can be completed through the following steps:
 Concatenate data in the method as specified in 5.3.6 of Security

Specification;
 Generate Hash value with the data above;
 Include Hash values in the signed dynamic application data;
 Use IC card private key to sign the signed dynamic

application data.
c) Include signed dynamic application data in the response for GENERATE

AC Command.
UPI Confidential 78
12.6 Processing Flow
Command:
GENERATE AC
A B
P1 indicates request cryptogram
type
The card supports No The card supports No

SDA? script processing?
Online authorization
indicator bit =1
Yes Yes
Yes
No The high nibble of byte 4 in
Indicator bit ‘SDA CVR indicates the value of
Set bit ‘Last online transaction fails’=1 issuer script command counter
is not completed’ in CVR
Yes
No
Set bit ‘SDA for last
transaction fails, and the No
transaction is rejected 'in The indicator bit ‘issuer
Set indicator bit ‘card request
CVR=1 script failure’=1
online transaction’
Yes
The card supports

Issuer authentication is Set the bit ‘issuer script
DDA?
supported processing for last online
transaction fails’in CVR=1
Yes Yes
Indicator bit ‘DDA No

No
Indicator bit ‘issuer failure’=1 C
authentication fails’=1?
Yes
No
Yes
Set bit’DDA for last
No transaction fails, and the
Set bit ‘issuer authentication for transaction is rejected in
last online transaction fails’in CVR=1
CVR =1
If ADA indicates issuer No

authentication for last online
transaction fails, will the transaction
be sent online?
Yes
Set indicator bit ‘ the card

A
requests for online’=1
Figure 8: Flow Chart of Card Action Analysis Processing (1)
UPI Confidential 79
C D E
The card performs

The card checks The card performs
international –
consecutive offline international – country
currency velocity
transaction? velocity check?
check?
YES
YES YES
ATC ATC Transaction Terminal

register of the last currency = country code =
YES issuer country YES
online transaction application
> lower limit of NO code?
currency?
consecutive offline
transaction?
NO NO
YES
Consecutive Consecutive
offline transaction offline transaction
Set ‘Velocity counter (international – counter (international
check on excess’ NO currency) +1 > – country) +1 >
NO Consecutive offline NO
bit in CVR = 1 Consecutive offline
transaction limit transaction limit
(international – (international –
currency)? country)?
NO
NO
YES YES
‘The card requests Set ‘Velocity Set ‘Velocity

online processing’ check is exceeded’ check is exceeded’
indicator bit = 1 bit in CVR = 1 bit in CVR = 1
‘The card requests ‘The card requests

for online’ for online’
D indicator bit = 1 indicator bit = 1
E F
UPI Confidential 80
F G
The
card performs The
transaction amount card performs transaction
amount (double NO
check in designated
currency? currencies) check?
YES YES
Transaction
Transaction Transaction
currency = second
currency=applicat NO currency =application NO application
ion currency? currency?
currency?
YES YES
YES
Accumulated
Accumulated transaction amount
transaction amount + (double currencies) + Use currency conversion
authorized amount > authorized amount > factor to convert into the
accumulated NO authorized amount in
accumulated transaction
transaction amount amount limit (double designated currency
limit? currencies)?
NO
Accumulated
YES transaction amount
YES (double currencies) +
YES authorized amount > NO
Set “Velocity check accumulated transaction
on excess” bit in CVR amount limit (double
=1 currencies)?
Set ‘Velocity check
on excess’ bit in
CVR = 1
Set “The card requests NO

for online” indicator
bit in CVR = 1
Set ‘The card
requests for online’
indicator bit in CVR
=1
NO
G
Figure 10: Flow Chart of Card Action analysis Processing (3)
UPI Confidential 81
H I
The card performs NO The card performs

“offline PIN verification is
new card check? not executed” check?
YES YES
last online ATC Offline PIN is

register = 0? NO NO supported?
YES YES
Set “New card” bit in The card receives VERIFY

CVR = 1 YES Command?
NO
NO PIN try counter = 0?

ADA indicates
“transaction shall NO
be online for a NO
YES
new card”?
Set “PIN try limit is
exceeded” bit in CVR
YES ADA indicates “the

transaction is rejected as PIN Set the card requests
YES offline rejection
try limit for last transaction is indicator bit
exceeded”?
Set the card requests
for online indication
bit = 1 NO
ADA indicates “the

transaction is rejected as PIN Set the card requests
YES for online indicator
try limit for last transaction is bit
I exceeded”?
NO
ADA indicates "if the PIN try

limit for last transaction is Reject the
exceeded, the transaction will YES transaction and lock
be rejected and the the application
application will be locked.
NO
UPI Confidential 82
The The Requests

terminal terminal requests TC
requests AAC or the card ARQC or the card
requests for offline NO requests for online NO
rejection indicator indicator
bit =1? bit =1?
YES Requests YESRequests

AAC ARQC
Set “the 1st GENERATE AC Set “the 1st GENERATE AC Command Set “the 1st GENERATE AC
Command returns AAC” and “the returns ARQC” and “the 2nd GENERATE Command returns TC” and “the
2nd GENERATE AC Command is AC Command is not requested in CVR 2nd GENERATE AC Command is
not requested in CVR not requested in CVR
Generate application Generate application Generate application

cryptogram cryptogram cryptogram
Set cryptogram type Set cryptogram type Set cryptogram type

in CID as AAC in CID as ARQC in CID as TC
ADA
indicates “Notice shall be Set “Online Reset “Online
generated if the transaction authorization” authorization”
rejected offline”? indicator bit = 1 indicator bit
YES
Set “Notice is The terminal The terminal

required” in CID requests CDA? requests CDA?
NO
YES YES
PIN Generate dynamic Generate dynamic
try limit of this signature for AC signature for AC
transaction is and CID with IC NO and CID with IC NO
exceeded? card private key card private key
YES
ADA indicates
“the transaction is rejected Respond to the 1st
and notice is generated as PIN NO GENERATE AC
try limit for the transaction Command L
is exceeded”?
NO GENERATE AC response
YES
Set “Notice is required” bit in
CID = 1 and the reason code is
“PIN try limit is exceeded”.
Figure 12: Flow Chart of Card Action analysis Processing (5)
UPI Confidential 83
K L
Offline Offline
rejection acceptance
Transaction Transaction
currency code = NO currency code =
SDA in TVR fails? YES Set SDA failure application currency second application
indicator bit code? currency code?
YES YES
Add the Convert the
NO accumulated authorized amount
transaction amount with the currency
with the authorized conversion factor
amount
DDA in TVR fails? YES Set DDA failure

indicator bit Add the Add the NO
accumulated accumulated
transaction amount transaction amount
(double currencies) (double currencies)
with the authorized with the converted
amount authorized amount
NO
Transaction
currency code =
application currency
code?
NO
Consecutive offline
transaction counter
(international –
currency) puls 1
YES
Terminal
country code = issuer
country code?
NO
Consecutive offline
transaction counter
(international –
country) puls 1 YES
Return response for

the 1st GENERATE
AC Command
GENERATE AC response
The terminal reads CDOL1 data and Transaction Detail Short File Identifier (SFI)
from the card.
The terminal sends the first GENERATE AC Command to the card requesting for
cryptogram. The Command includes terminal data designated in CDOL1 which can
UPI Confidential 84
be used to GENERATE Application Cryptogram and perform Card Risk

Management.
Online Processing
The terminal decides whether online authorization shall be performed based on the
cryptogram type returned to GENERATE Application Cryptogram Command.
Completion
If online authorization is requested while the terminal has no online capability, the
card will perform other kinds of risk management.
Some counters and indicator bits in the card will be reset based on Issuer
Authentication status and card option regarding Issuer Authentication.
UPI Confidential 85
13 Online Processing
Online Processing allows the issuer to check the transaction based on risk
management parameters in its host system and make transaction approval or
decline decisions. Besides traditional online check, the host authorization system
can use the dynamic cryptogram generated by the card to perform Online Card
Authentication and can consider transaction offline processing results in the
authorization decision.
Response of the issuer can include post-issuance updates to the card and a
cryptogram generated by the issuer. The card verifies the cryptogram to guarantee
that the response comes from a valid issuer. This validation is called Issuer
Authentication.
This Chapter describes online processing function of the card.
13.1 Card Data
The table below specifies card data used by the terminal during Online Processing.
Table 34: Generate Application Cryptogram Response - Card Data
Cryptogram Information Data

It includes the indicator bit that indicates the cryptogram type.
(CID)
Application Transaction It is the transaction counter initialized when the card

Counter (ATC) establishes the application.
Application Cryptogram The online cryptogram (ARQC) value from the card.
Issuer Application Data is UnionPay mandatory data, which is

used to transmit the data defined by UnionPay to the terminal
and then put in the online request message or clearing
message. The data includes the following data elements:
 Length indicator;
Issuer Application Data
 Derivation key index (DKI);
 Cryptogram version number;
 Card Verification Results (CVR);
 Issuer discretionary data (optional).
The table below specifies the card data used by the terminal after it receives online
request.
UPI Confidential 86
Table 35: Issuer Authentication Decision - Card Data
AIP data is transmitted from the card to the terminal during

Application Interchange
application initialization. If the card supports issuer
Profile (AIP)
authentication, the “Issuer authentication” bit in AIP is “1”.
The table below specifies the data applied by the card during issuer authentication.
Table 36: Online Processing and Issuer Authentication - Card Data
It is the application Cryptogram generated by the card during

Authorization Request
Card Action Analysis. It is used to validate the Authorization
Cryptogram (ARQC)
Response Cryptogram (ARPC).
CVR includes the following flags related to issuer

authentication:
Card Verification Results  Issuer authentication is performed unsuccessfully;

(CVR)  Issuer authentication for the last online transaction fails;
 Issuer authentication after online transaction is not

performed.
Issuer Authentication Failure

If the issuer authentication fails, the card sets the indicator to 1
Indicator
Application Cryptogram (AC)

It is the secret DES key used by the card to validate ARPC.
Key
13.2 Online Response Data
Online response from the issuer to the terminal is specified in the table below. The
terminal uses EXTERNAL AUTHENTICATE Command to send the data to the
card for Issuer Authentication. Except for the data below, online response can also
include issuer Script data.
Table 37: Online Processing - Terminal data
UPI Confidential 87
It is data that the terminal includes in the EXTERNAL

AUTHENTICATE Command sent to the terminal. It includes:
Authorization response cryptogram (8 bytes) generated by

Issuer Authentication Data
the issuer’s host (or agent);
Authorization response code (2 bytes) - used for ARPC

calculation.
13.3 Command
EXTERNAL AUTHENTICATE Command
If Issuer Authentication should be performed, the terminal sends EXTERNAL

AUTHENTICATE Command to the card.
EXTERNAL AUTHENTICATE Command includes issuer authentication data

from the online response.
Response code of EXTERNAL AUTHENTICATE Command indicates whether

the issuer authentication has been successfully validated. If yes, the card will
respond SW1 SW2=“9000”; otherwise, the card will respond “6300”.
In one transaction, the card allows processing at most one EXTERNAL

AUTHENTICATE Command. All succeeding EXTERNAL AUTHENTICATE
Commands, the card will respond always SW1 SW2 = “6985”.
For command encoding, please refer to Appendix B.
13.4 Processing
Online processing consists of three parts: online request processing, online

response processing and issuer authentication. The card performs processing only
in issuer authentication.
13.4.1 Online Request
After the terminal receives ARQC from the card and the terminal has online
capability, the terminal will send an online request. The online request includes the
data obtained by the terminal from the card during previous steps. During this stage,
the card has no processing.
13.4.2 Online Response
The card does not conduct any steps during receiving the online response from the
issuer.
UPI Confidential 88
13.4.3 Issuer Authentication
If AIP data in the card indicates that the card supports issuer authentication, and
online response received by the terminal includes issuer authentication data, the
terminal will issue an EXTERNAL AUTHENTICATE Command to the card.
When the card receives the EXTERNAL AUTHENTICATE Command, it

performs issuer authentication in the following steps:
1. If an EXTERNAL AUTHENTICATE Commands was previously received

during current transaction:
 Set issuer authentication failure indicator bit as “1”;
 Respond to the terminal with SW1 SW2=“6985”.
2. Parse out the authorization response code from issuer authentication data and
store it for further application during completion processing function.
3. Use ARQC and the authorization response code generated for response to the
1st GENERATE AC Command to generate an Authorization Response
Cryptogram (ARPC). For key and algorithm for cryptogram generation, please
refer to Appendix D.
4. Compare the newly generated ARPC with the ARPC received from the
EXTERNAL AUTHENTICATE Command. If these two are the same, the
Issuer Authentication can be considered successful.
If Issuer Authentication is successful, the card shall:
1. Set Issuer Authentication Failure Indicator bit as “0”;
2. Indicate that the Issuer Authentication was successful in the EXTERNAL

AUTHENTICATE Command response with “9000” to the terminal.
If Issuer Authentication is not successful, the card shall:
1. Set Issuer Authentication Failure Indicator bit as “1”;
2. Set “Issuer Authentication Performed and Failed Indicator” bit in CVR as “1”;
3. Indicate that the Issuer Authentication failed in the EXTERNAL

AUTHENTICATE Command response with “6300” to the terminal.
The card shall ensure that the Issuer Authentication Failure Indicator remains set to
“1” when it is removed from the terminal after the completion of the transaction.
During the next transaction, the indicator bit shall be checked in the Card Action
Analysis to decide whether the transaction shall be sent online for authorization.
During completion processing, the card shall be able to check whether issuer
authentication is performed successfully since the response to the final
UPI Confidential 89
GENERATE APPLICATION CRYPTGRAM may be dependent upon these

results.
13.5 Processing Flow
Card Terminal
The card receives EXTERNAL The terminal sends

EXTERNAL AUTHENTICA EXTERNAL
AUTHENTICATE TE Command AUTHENTICATE
Command Command to the card
1st EXTERNAL
AUTHENTICATE NO Respond 6985
Command?
YES
Use ARQC and

authentication
response code to
generate a
cryptogram
Cryptogram NO Respond 630

generated = ARPC
YES
Set “Issuer
authentication fails” Set “Issuer
indicator bit = 0 authentication fails”
indicator bit = 1
Set “Issuer
authentication is
Respond 9000 performed
unsuccessfully” bit in
=1
External authentication
Return command response The terminal
response to the receives
terminal response from
the card
Figure 14: Online Processing Flow Chart
The card returns AIP to the terminal in the GET PROCESSING OPTIONS
command response. AIP indicates whether the card supports issuer authentication.
The card returns the Application Cryptogram in response to the 1st GENERATE
AC Command.
Completion
During completion, the card uses issuer authentication results to determine final
results of the transaction and reset some counters and indicators.
Issuer-to-Card Script Processing
UPI Confidential 90
The terminal will send all issuer Script Commands included in the online response
to the card. The card may consider Issuer Authentication results in deciding
whether to apply issuer scripts
Card Action Analysis (Subsequent Transaction)
If the online authentication indicator bit indicates that online processing of the
previous transaction is not completed, the card will request online authorization for
this transaction.
UPI Confidential 91
14 Completion
The terminal and the card perform the following Completion steps to conclude the
transaction processing:
 If online processing is requested, but the terminal does not support online or
online authorization is not completed, the terminal and the card perform
additional analysis to determine whether the transaction shall be approved or
declined;
 An issuer’s online approval may be changed to a decline based on issuer

authentication results and some settings in the card;
 Some counters and indicator bits will be set to record what has occurred during
transaction processing;
 After online authorization is completed, some counters and indicators will be

reset based on Issuer Authentication status and some settings in the card.
14.1 Card Data
The table below specifies the data used by the card during Completion.
Table 38: Completion - Card data
Application currency code It indicates the domestic currency related to the

(9F51) application.
Application Default Action It is the indicator defined by the issuer to specify card
(ADA) actions under certain special circumstances.
Application Interchange Profile It includes the indicator bits that indicate the card supports
(AIP) Issuer Authentication.
UnionPay dedicated data. It records the times of offline

transactions in non-designated currencies ever since the
counter (international-currency)
last online authorization.
UnionPay dedicated data. It records the times of offline

transactions whose Terminal Country Code differs from the
Issuer Country Code ever since the last online
counter (international-country)
authorization. The check uses Issuer Country Code to
decide whether the transaction is domestic or international.
UPI Confidential 92
UnionPay dedicated data. It records the total amount of

offline transactions in application designated currency ever
amount
since the last online processing.
UnionPay dedicated data. It records the total amount of

offline transactions in application designated currency
Accumulated offline transaction (Application Currency Code) and second application
amount (dual currencies) currency ever since the last online processing. For second
application currency, the authorized amount shall be
converted with currency conversion factor before adding.
UnionPay dedicated data. It is the maximum limit on

Upper limit of accumulated accumulation of accumulated offline transaction amount
offline transaction amount and accumulated offline transaction amount (dual
currencies).
It is the exchange rate used to convert the second

application currency to the application designated
Currency conversion factor currency. Amount in second application currency
multiplied by the conversion factor is the amount in
application designated currency.
It indicates that DDA for this transaction or the previous

DDA failure indicator
transaction fails.
It indicates that issuer authentication for this transaction or

Issuer authentication failure
the previous transaction fails. It is used in Card Action
indicator
Analysis of the follow-up transactions.
It indicates whether Issuer Authentication is mandatory or

optional.
Issuer Authentication indicator If Issuer Authentication is mandatory, the card must

receive and successfully process an ARPC (i.e. through
Issuer Authentication) to reset ATC last online register and
offline counter.
Issuer country code (9F57) UnionPay dedicated data. It indicates country of the issuer.
It records the quantity of issuer Script Commands with

Issuer Script Command counter
Secure Messaging during the previous online transaction.
UPI Confidential 93
It is set when issuer script processing for the last online

Issuer Script failure indicator bit
transaction fails.
ATC register for the last online It is the ATC value for the last online authorized
transaction transaction that meets Issuer Authentication requirements.
It is the application indicator when the requested online

Online authorization indicator transaction cannot be sent online or online authorization is
suspended.
It is used for velocity check on dual currencies. It can use

Second application currency
currency conversion factor for application currency
code
conversion.
It indicates that SDA for the current or last transaction

SDA failure indicator
fails.
UnionPay dedicated data. It records the maximum of

Upper limit for consecutive
consecutive offline transactions which cannot get online or
offline transactions
offline approval
The table below specifies the response data used by the card during completion to
generate Application Cryptogram.
Table 39: Response to GENERATE Application Cryptogram Command
It includes the following indicator bits:
Cryptogram type:
- An AAC for a decline;

Cryptogram Information Data - A TC for an approval;
-An ARQC when online processing is requested ( first

GENERATE AC only).
Other status information including Service Not Allowed
Application transaction counter It is the transaction times counter initialized when the
(ATC) application is established on the card.
UPI Confidential 94
It is the value of cryptogram. If the card performs CDA

and Cryptogram Information Data indicates that
Application Cryptogram (AC) cryptogram is TC or ARQC, Application Cryptogram and
other data shall be included in an asymmetric digital
signature.
It includes proprietary application data to be submitted to

Issuer application data the issuer, including CVR:
 Card Verification Results  UnionPay dedicated data element. It indicates the

(CVR) offline processing results of the current and the
previous transactions.
The table below specifies the card data used by the terminal during Completion.
Table 40: Completion - Card Data used by the Terminal
The list specifies the data objects (tag and length) required
by the card from the terminal in the 2nd GENERATE AC
Command. Besides, the data tags required in Cryptogram
Algorithm, the following data must be applied in
transaction closing in CDOL2:
 Authorized amount (If velocity check on application

amount is supported);
 Authorization response code;
 Terminal Verification Results (TVR);
 Transaction currency code (If check requiring

currency code supported);
 Terminal country code (If check requiring country

code supported).
Data elements in CDOL shall not be repeated.
14.2 Terminal Data
The table below specifies the terminal data used by the card during Completion.
Table 41: Completion - Terminal Data
UPI Confidential 95
Authorized amount It indicates the amount of the transaction.
It indicates the transaction processing results and shall be

submitted to the card.
 Y1= offline approved;

Authorization response code
 Z1= offline declined;
 Y3= cannot get online (offline approved);
 Z3= cannot get online (offline declined).
Terminal Verification Results It is used to record the offline processing results, such as
(TVR) SDA failure or floor limit exceeded, etc.
Terminal country code It indicates the country where the terminal is located.
Transaction currency code It indicates the currency applied in the transaction.
14.3 Command
GENERATE Application Cryptogram Command
The terminal sends the 2nd GENERATE AC Command to the card requesting for
the 2nd Application Cryptogram.
Data element of the Command includes terminal data specified in CDOL2,

including authorization response code.
Parameter P1 in the Command indicates the application cryptogram type requested

by the terminal.
Response information of the Command includes Cryptogram Information Data,

card authorization results, Application Transaction Counter (ATC), Application
Cryptogram and issuer discretionary data. Discretional data includes CVR
indicating the processing results.
For details of the 2nd GENERATE AC Command, please refer to Appendix B.
14.4 Completion Processing Overview
The card only performs Completion processing when the card requested an online
authorization during Card Action Analysis.
At the end of Card Action Analysis, the card will:
UPI Confidential 96
 Request for offline approval or decline. For these transactions, card processing
is complete with Card Action Analysis. The card performs no Completion
processing.
 Request for online authorization. Then the card shall perform Completion
processing for these transactions.
The figure below is the flow chart for Completion processing.
The card receives the last

GENERATE AC Command sent
by the terminal
NO Authorization YES
Online authorization Online authorization
is completed response code = Y3 or Z3? is not completed
The terminal requests Perform card risk

AAC TC
for AAC or TC? management
Authorization
NO response code = acceptance
code?
The
terminal or the card risk
NO YES
management requests for
Respond AAC AAC?
YES
The
card accepts
Accept or rejects the Reject Respond TC Respond AAC
transaction?
Reset the pointer Respond AAC
Respond TC
Figure 15: Flow Chart for Transaction Closing Processing
14.5 Receive GENERATE AC Command
After the card receives the 2nd GENERATE AC Command, it performs Completion
processing. Based on the authorization response code type in the command,
Completion processing can be performed in two ways: online authorized
transaction (14.6) and request online operation, but online authorization is not
completed (14.7).
UPI Confidential 97
14.6 Transaction Authorized Online
When the transaction was authorized online (Authorization response code is not Y3
or Z3), the card does the following:
 Verify the authorization response code received in the EXTERNAL

AUTHENTICATE Command if issuer authentication was performed:
 Authorization response code is 00, 10 or 11, which indicates that the

issuer approves the transaction;
 Authorization response code is 01 or 02, which indicates the issuer

requests for referral.
 Other values indicate that the issuer declines the transaction. And the
terminal needs to request for transaction decline.
 Check Parameter P1 in the 2nd GENERATE Application Cryptogram

command:
 If P1 indicates a TC (Approval cryptogram) and, if verified above, the

authentication response code indicates the issuer approval or referral,
approval processing shall be performed. For details, please refer to 14.6.2.
 If P1 indicates an AAC (decline cryptogram) or, if verified above, the

authentication response code indicates a decline, decline processing shall
be performed. For details, please refer to 14.6.1 Request AAC after
Online Authorization.
14.6.1 AAC (Decline) Requested after Online Authorization
When the card receives a request for an AAC in the 2nd GENERATE AC
Command or the authorization response code indicates an issuer decline, the card
shall return an AAC. But before that, the card will:
 Set the bits in the CVR as 1 to indicate that an AAC is returned in The 2nd
GENERATE AC Command response;
 Set “Issuer authentication not performed after online authorization” bit in CVR
as “1” if AIP indicates that issuer authentication is supported but not
performed;
 Set “Issuer authentication failure” indicator bit as “1” if issuer authentication is

mandatory (indicated by the issuer authentication indicator) but not performed;
 Reset the following indicator bits if the issuer authentication is: (1) not
supported, or (2) optional but not performed, or (3) performed successfully:
 Online authorization indicator;
 SDA failure indicator;
UPI Confidential 98
 DDA failure indicator;
 Issuer Script Command counter;
 Issuer Script failure indicator.
 Keep the following indicator bits the unchanged:
 ATC register of the last online transaction;
 Accumulated offline transaction amount;
 Accumulated offline transaction amount (dual currencies);
 Consecutive offline transaction counter (international-currency);
 Consecutive offline transaction counter (international-country).
 Generate Application Cryptogram;
 Set cryptogram type in Cryptogram Information Data as AAC;
 Return the 2nd GENERATE AC Command response to the terminal.
14.6.2 TC (Approval) Requested after Online Authorization
When the card receives a request for a TC in the 2nd GENERATE AC Command,
and, if checked, the authorization response code indicates an issuer approval or
referral, the card will perform the following:
 Set “Issuer authentication not performed after online authorization” bit in CVR
as “1” if AIP indicates that issuer authentication is supported but not
performed;
The card can decide whether to approve or decline the transaction based on
issuer authentication settings.
 Card Approve - If any of the following conditions is satisfied, the card will
approve the transaction:
 Issuer authentication is successfully completed;
 AIP indicates that issuer authentication is not supported;
 Issuer authentication is optional and not performed;
 Issuer authentication failed, and ADA bit for “If Issuer Authentication
Performed and Failed, Decline Transaction” is set as “0”;
 Issuer authentication is mandatory but not performed, and ADA bit for “If
Issuer Authentication is mandatory and no ARPC received, Decline
Transaction” is set as “0”.
UPI Confidential 99
The follow-up procedures for “card approves transaction” shall be performed. For
details, please refer to 14.6.2.1 Card Accepts Transaction after Receipt of TC
Request.
 Card Decline - If any of the following conditions is satisfied, the card will
decline the transaction:
 Issuer authentication failed, and the ADA bit for “If Issuer authentication
Performed and Failed, Decline Transaction” is set as “1”;
 Issuer authentication is mandatory but not performed, and the ADA bit for
“If Issuer Authentication is mandatory and no ARPC, Decline
Transaction” is set as “1”.
The follow-up procedures for “card declines transaction” shall be performed. For
details, please refer to 14.6.2.2 Card Rejects Transaction after Receipt of TC
Request.
14.6.2.1 Card Approves Transaction after TC (Approval) Requested
When the card approves the transaction, it will:
1. Set the bits in the CVR as 1 to indicate that a TC is being returned in The 2nd
2. Set cryptogram type in CID as TC in the GENERATE AC response;
3. Reset counters and indicators based on issuer authentication results and

requirements as steps 3a and 3b:
a) If issuer authentication (1) failed, or (2) is mandatory but not performed,

the card will:
 Keep the values of the following the same:
 ATC registers for the last online transaction;
 Accumulated offline transaction amount;
 Accumulated offline transaction amount (dual currencies);
 Consecutive offline transaction counter (international-currency);
 Consecutive offline transaction counter (international-country);
 Online authorization indicator ;
 SDA failure indicator ;
 DDA failure indicator ;
 Issuer Script Command counter;
UPI Confidential 100

 Issuer Script failure indicator.
 If issuer authentication is mandatory but not performed, the card will:
 Set issuer authentication failure indicator bit as “1”;
 Set “Issuer authentication not performed after online

authorization” bit in CVR as “1”.
b) If Issuer Authentication (1) is performed successfully, or (2) is optional

but not performed, or (3) is not supported, the card will:
 Set “Issuer authentication not performed after online authorization”

bit in CVR as “1” if AIP indicates issuer authentication is supported
but the card has not received the EXTERNAL AUTHENTICATE
Command;
 Reset the following counters and indicator:
 Online authorization indicator;
 SDA failure indicator;
 DDA failure indicator;
 Issuer Script Command counter;
 Issuer Script failure indicator;
 Accumulated offline transaction amount;
 Accumulated offline transaction amount (dual currencies);
 Consecutive offline transaction counter (international-currency);
 Consecutive offline transaction counter (international-country).
 Change value of the ATC register for the previous online transaction
into ATC of the current transaction.
4. Generate Application Cryptogram;
5. The card records the transaction details. The contents will be transmitted to the
card through GET PROCESSING OPTIONS Command during transaction
initialization stage. For descriptions on card transaction details, please refer to
Chapter 19.
6. Return the 2nd GENERATE AC response to the terminal.
14.6.2.2 Card Declines Transaction after TC (Approval) Request
When the card has declined the transaction where an approval was requested, it
will:

 Set the bits in the CVR as 1 to indicate that an AAC is being returned in the 2nd
 Set “Issuer authentication failure” indicator bit as “1” if issuer authentication is

supported and mandatory;
 Set application cryptogram type in CID in the GENERATE AC response as

AAC;
 Set “Advice required” bit in CID as “1” if the ADA bit for “If Transaction
Declined Because Issuer Authentication failed or Not Performed, Create
Advice” is set as 1
 Keep the values of the following counters the same:
 Accumulated offline transaction amount;
 Accumulated offline transaction amount (dual currencies);
 Consecutive offline transaction counter (international-currency);
 Consecutive offline transaction counter (international-country);
 ATC register for the last online transaction;
 SDA failure indicator;
 DDA failure indicator;
 Issuer Script Command counter;
 Issuer Script failure indicator.
The card will:
 Return the 2nd GENERATE Application Cryptogram response to the terminal.
14.7 Online Processing Requested, but Online Authorization Not Completed
When the authorization response code is included in the 2nd GENERATE AC

Command indicates that online processing is requested but not completed (Y3 or
Z3), the card will:
 Perform the optional card risk management which are supported; refer to
14.7.1 Card Risk Management;
 Respond to the terminal; refer to 14.7.2 Card Response after the Transaction
cannot be sent Online.

14.7.1 Card Risk Management
Card Risk Management includes optional checks to determine whether the times of
consecutive offline transactions has exceeded upper limit of consecutive offline
transactions, whether accumulated amount of consecutive offline transactions has
exceeded the limit, whether the card is a new one, and whether PIN try limit has
been exceeded during the previous transaction.
When online authorization was not completed, even if the terminal requests
transaction decline (AAC) in the 2nd GENERATE AC Command or the card
decides to decline the transaction during previous risk management, the card will
still perform all card risk management supported. As the card performs all checks,
the order in which the checks are performed need not conform to the order
described below.
14.7.1.1 Velocity Check on Upper Limit of Consecutive Offline Transactions
The check is optional. The aim is to check whether the times of consecutive offline
transaction exceed the maximum limit.
If ATC register of the last online transaction and UnionPay dedicated data - Upper
limit of consecutive offline transaction (tag “9F59”) exist, the card will perform the
check.
If the difference between ATC and last online ATC register exceeds upper limit for
consecutive offline transactions, the card will:
 Set “Exceeded Velocity checking Counters” bit in CVR as “1”;
 Set “Offline Declined requested by card indicator” bit as “1” to indicate that an
AAC should be returned after completion of card risk management.
14.7.1.2 New Card Check
The check is optional. The aim is to check whether the card has any transaction
approved online before.
If ATC register of the last online transaction does exist in the card, the card will
perform the check. If ADA does not exist, the card will take the default value
“0”.
If ATC register for the last online transaction is zero, the card will:
 Set “New card” bit in CVR as “1”;
 If the ‘ADA bit for IF New Card, Decline if Unable to Transmit Online’ is set
as ‘1’, the card sets the ‘offline Decline Requested by Card’ Indicator to ‘1’ to
indicate that an AAC should be returned after completion of card risk
management.
14.7.1.3 PIN Try Limit Exceeded

This check is optional. The aim is to check whether PIN try limit has been
exceeded during previous transactions.
If the ADA is not present, the card will take ADA as default value of zero.
If the card supports offline PIN verification, and the card has not received VERIFY
Command from the terminal during the current transaction, the card will:
 If PIN try counter is zero and the ADA bit for ‘if PIN Try Limit Exceeded on
Previous Transaction, Decline If Unable to Transmit Transaction Online (Byte
2 bit 5)’ is set as ‘1’
 Set “Offline Decline Requested by Card Indicator’ bit as “1”;
 Set “PIN Try Limit Exceeded” bit in CVR as “1”.
14.7.1.4 Velocity Check on (Upper Limit for) Accumulated Offline

Transaction Amount
The check is optional. The aim is to check whether the accumulated amount of
consecutive offline transaction in the primary currency exceeds the upper limit or
not.
If accumulated offline transaction amount and upper limit for accumulated offline
transaction amount exist, the card will perform the check.
If the sum of accumulated offline transaction amount and authorized amount of the
current transaction is more than the upper limit of accumulated offline transaction
amount,
The card will:
 Set the “Exceeded Velocity checking Counters” bit in CVR as “1”;
 Set the “Offline Decline Requested by card indicator” bit as “1”.
14.7.1.5 Velocity Check on Upper Limit of Accumulated Offline Transaction

Amount (Dual Currencies)
The check is optional. The aim is to check whether the accumulated amount of
consecutive offline transaction in designated currency and second application
currency exceeds the upper limit or not.
If accumulated offline transaction amount (dual currencies) and upper limit of

accumulated offline transaction amount exist, the card will perform the check.
If the sum of accumulated offline transaction amount and authorized amount of the
transaction (for second application currency, the amount shall be converted with the
currency conversion factor at first) is more than the upper limit of accumulated
offline transaction amount,
The card will:

 Set the “Exceeded Velocity checking Counters” bit in CVR as “1”;
 Set the “Offline Decline Requested by Card indicator” bit as “1”.
14.7.2 Card Response after Unable to Go Online
Based on the application cryptogram type requested by the terminal and card risk
management results, the card will respond to the 2nd GENERATE AC Command
issued by the terminal as follows.
If any of the following conditions is satisfied, the card will decline the transaction:
 The terminal requests an AAC in the second GENERATE Application

Cryptogram Command;
 The result of card risk management is that the “Offline Decline Requested by
Card indicator” bit as “1”
For transaction decline processing, please refer to 14.7.2.1 Card decline the
Transaction after unable to go Online.
If all the following conditions are met, the card will approve the transaction:
 The terminal requests a TC in the second GENERATE Application Cryptogram

Command;
 The result of card risk management is that the “Offline Decline Requested by
Card indicator” bit as “1”.
For transaction approve processing, please refer to 14.7.2.2 Card Approves the
Transaction after Unable to Go Online.
14.7.2.1 Card Decline the Transaction after Unable to Go Online
This section describes how the card declines the transaction when online processing
is requested for the transaction but online authorization is not able to be completed
(authorization response code is Y3 or Z3). The card will:
 Set the following indicator bits in CVR:
 Return AAC in the 2nd GENERATE AC response;
 The terminal was “Unable to Go Online”
 Set SDA failure indicator bit as “1” if “SDA failure” bit in TVR is “1”;
 Set DDA failure indicator bit as “1” if “DDA failure” bit in TVR is “1”;
 Set CDA failure indicator bit as “1” if “CDA failure” bit in TVR is “1”;
 Increase consecutive offline transaction counter (international-country) by 1 if

the terminal country code differs from the issuer country code;

 Increase consecutive offline transaction counter (international-currency) by 1 if

the transaction currency code differs from the application currency code;
 Set “Advice Required” bit in CID as “1” if “Transaction Declined Offline,

Create Advice ” bit in ADA is “1”;
 Keep the value of ATC register for the last online transaction the same;
 Set application cryptogram type to an AAC;
 Return the second GENERATE AC response to the terminal.
14.7.2.2 Card Approved the Transaction after Unable to Go Online
This section describes how the card approves the transaction when online
processing is requested for the transaction but online authorization is not able to be
completed (authorization response code is Y3 or Z3). The card will:
 Set the following indicator bits in CVR:
 Return a TC in the 2nd GENERATE AC response;
 The terminal was “Unable to for online”.
 Increase consecutive offline transaction counter (international-country) by 1 if

the terminal country code differs from the issuer country code;
 If the transaction currency code differs from the application currency code,
 Add the accumulated offline transaction amount with the authorized

amount;
 Add the accumulated offline transaction amount (dual currencies) with

the authorized amount.
 Increase consecutive offline transaction counter (international-currency) by 1 if

transaction currency code differs from application currency code;
 Add the accumulated offline transaction amount (dual currencies) with the
converted authorized amount if transaction currency code is the same as the
second application currency code;
 Keep value of ATC register for the last online transaction the same;
 Set cryptogram information data to a TC;
 Record transaction details. The detailed content is transmitted to the card

through GET PROCESSING OPTIONS Command during the transaction

initialization stage. For contents of transaction details, please refer to Chapter

16.
 Return the second GENERATE Application Cryptogram response to the

terminal.
14.8 Response to Combined Dynamic Data Authentication/ Generate Application

Cryptogram
If any of the following situations occurs, the card will perform CDA:
 CDOL2 in the card includes terminal capability data tags, and the terminal
capability data from the terminal and Application Interchange Profile (AIP) in
the card both indicate that CDA is supported.
 CDOL2 in the card does not include terminal capability data tags, and
Parameter P1 in GENERATE AC Command from the terminal has a CDA bit
of “1”.
The card will:
1. Generate Application Cryptogram based on the descriptions above.
2. Carry out no special processing if the card responds AAC;
3. Use IC card private key to sign the application cryptogram responded by the
card as the signed dynamic application data if the card responds TC. The
procedures are as follows:
a) Set “DDA is performed” bit in CVR as “1”. The procedure will be

performed before the step 1 of GENERATE Application Cryptogram;
b) Use application cryptogram to generate a dynamic cryptogram. Refer to

5.3.6 of the Security Specification for details. The following part
summarizes the four steps:
 Organize data based on descriptions in 5.3.6 of the Security

Specification. The data include IC card dynamic data (including
length of the ICC dynamic data, IC card dynamic number,
cryptogram information data and application cryptogram, etc.);
 Make a Hash calculation based on the data above;
 Include the Hash value in the signed dynamic application data;
 Use IC card private key to sign the signed dynamic application data.
c) Respond information including signed dynamic application data in the

GENERATE AC Command.

14.9 Flow Chart
The figures below are flow charts for the card to perform Completion processing.
The card receives the

last GENERATE AC
Command
The
Authentication transaction
response code = Y3 or Y can not get
Z3? online
Requested AC type Online

is TC and response code is Y acceptance
not rejection?
Set return AAC for the

2nd GENERATE AC
Command in CVR
Issuer
authentication
supported?
Issuer Set “Issuer authentication is

authentication N not performed after online
performed? authorization” bit in CVR as 1
Y
N
Issuer
authentication
succeeded?
Issuer
Y authentication
Y N optional?
Reset to zero:
- Online authorization indicator bit;
- SDA failure indicator bit; N
- DDA failure indicator bit;
- Issuer script command counter;
- Issuer Script failure indicator bit.
Set Issuer authentication
failure indicator bit
The card generates

cryptogram response
command
Figure 16: Transaction Flow Chart (1)

online
accepta Authentication response
nce code is not Y3 or Z3,
and TC is requested
Issuer Card
authentication NO accepts
supported?
YES
Issuer
authentication
performed?
NO
Issuer Card
authentication YES accepts
optional?
NO
Set “Issuer
authentication
failure” indicator bit
=1
YES
“The transaction
is rejected as issuer Card
authentication is mandatory NO accepts
but ARPC is not received”
bit in ADA = 1?
YES
Card
rejects
Issuer authentication Card

succeeded? YES accepts
NO
“The transaction is Card

rejected as issuer YES rejects
authentication fails” bit in
ADA = 1?
NO
Card
accepts

Card Card
accepts rejects
Set cryptogram Set cryptogram

type in CVR as type in CVR as
TC AAC
Set cryptogram Set cryptogram

type in CID type in CID
G
Issuer
authentication NO
supported?
YES Reset to zero:

- Online authorization indicator;
Issuer - SDA failure indicator;
authentication NO - DDA failure indicator;
performed? - Issuer Script Command counter;
- Issuer Script failure indicator;
- Accumulated transaction amount;
NO - Accumulated transaction amount
(double currencies);
Set “Issuer - Consecutive offline transaction
authentication is not counter (international – currency);
performed after online - Consecutive offline transaction “Notice is
authorization” bit in counter (international – country). generated as issuer
CVR as 1 authentication fails or is not
mandatory performed” bit
YES
Issuer ATC register for inADA = 1?
authentication the last online
mandatory? transaction = ATC
YES YES
Set “Notice is
required” NO
Issuer indicator bit in
CID as 1
authentication NO
succeeded?
YES
Generate
cryptogram
G
Corresponding
command

Can not get

online C
Authorization
response code
indicates that the The card supports
transaction can not offline PIN?
get online
YES
ATC – ATC
register of the last online
transaction > Upper limit of
consecutive offline The card receives
transaction? VERIFY Command? YES
NO NO
Accumulated PIN try limit has been

YES transaction amount + exceeded during the NO
NO authorized amount >Upper last transaction?
limit of accumulated
transaction amount?
YES
NO
“The
Accumulated transaction is rejected NO
transaction amount (double as PIN attempt limit is NO
currencies) + authorized exceeded during the
YES amount >upper limit of last transaction” bit in
accumulated transaction ADA = 1
amount?
Set “Velocity
check on excess” YES
bit in CVR = 1
Set “card request
rejection” indicator bit
=1
Set “card requests NO
rejection” indicator
bit = 1
Set “PIN try limit is
exceeded” bit in CVR =
1
ATC
register of the last
online transaction
= 0? Set “Can not be
forwarded online” bit
in CVR = 1
YES
Set “New card” bit

in CVR = 1
Can not
be
forwarded
online
“The
transaction is
NO rejected as the card is
a new one” bit in
ADA = 1?
NO
YES
Set “Card requests

rejection” indicator
bit as 1

Offline rejection
Can not
get
online
Set “The 2nd
GENERATE
AC Command”
bit in CVR
Issuer Increase offline

country code = transaction
terminal country NO counter
code? (international –
currency) by 1 TVR
indicates Set SDA failure
thatSDA YES indicator bit = 1
fails?
YES
NO
Transaction Increase offline
currency code transaction
= application NO counter TVR
currency (international – indicates Set DDA failure
country) by 1 that DDA YES indicator bit = 1
code? fails?
YES
YES NO
The
terminal YES “Notice
requests for is required if the
AAC? transaction is rejected”
bit in ADA = 1?
NO
“Card YES
requests
rejection”
indicator bit Set “Notice is
= 1? required” bit in NO
CID
Offline
NO approval
“Card Add accumulated

requests transaction amount Set cryptogram
rejection” YES with authorized type AAC in
indicator amount CID
bit = 1?
NO Add accumulated transaction

amount (double currencies) with
authorized amount
Transaction
currency code = Convert the authorized
YES amount with the currency
application currency conversion factor
code?
Add accumulated
transaction amount
(double currencies)
NO with converted Generate
authorized amount Application
cryptogram
nd
Set “The 2
GENERATE AC
Command returns TC”
bit in CVR The card
responds to the
2nd
GENERATE
Set cryptogram AC Command
type in CID
Transaction Detail File Short File Identifier is read from the card.
The card requests an online authorization, an offline approval or an offline decline

after card action analysis. During Completion, the terminal only sends a second
GENERATE AC command to the card for transaction where the card requested an
online authorization. The card does not conduct Completion processing for
transactions where the card requested an offline approval or offline decline during
Card Action Analysis.
Online Processing

If the card receives EXTERNAL AUTHENTICATE Command from the terminal,

it will validate ARPC in the Command and set the indicators as “Issuer
Authentication Performed successfully” or “Issuer Authentication Performed
unsuccessfully”.
Card Action Analysis (Subsequent Transaction)
On the following transaction, the card will use counters and indicator bits set
during Completion to make decisions and perform checks.

15 Issuer-to-Card Script Processing
Issuer-to-Card script processing enables issuers to change personalized data on card

without re-issuance. The issuer will put the Issuer Script in the authorization
response message and send to the terminal, and the terminal will transfer these
commands to the card. When security requirements are satisfied, the card will
execute the commands.
The supported commands include:
 Update card parameters;
 Block or unblock application;
 Block the card;
 Reset PIN try counter;
 Change offline PIN value.
Issuer-to-Card Script Processing limits credit and fraud exposure by allowing

blocking of overspent and stolen cards. Card parameters can be changed based on
actual situations of the cardholder without re-issuing the card.
15.1 Card Data
The table below specifies the counters and indicator used by the card during Issuer
–to-Card Script Processing.
Table 42: Issuer Script Processing - Card Data
It is the counter which will be increased by 1 for each

Application transaction counter (ATC) transaction. It is used to in the generation of session
key used during script processing.
During card action analysis of the subsequent

transactions, some fields in CVR are set:
- Number of issuer script commands received after the

second GENERATE Application Cryptogram (AC)
command containing secure messaging processed on
last transaction, contains value from Issuer Script
Command Counter
- The issuer Script Processing Failed on Last

Transaction Indicator bit is set as “1” — if the issuer
script failure indicator bit is “1”.

Used by the card to count each command containing

secure messaging that was received after the second
Issuer Script Command counter GENERATE AC command. On Subsequent
transaction this counter may be reset during
Completion.
The card shall set the Issuer Script Failure indicator to

“1” if one of the following error conditions occurs
during card processing of a command received after
the second GENERATE AC command:
- Secure message failed (calculated MAC differs from

MAC in the command);
- Secure message passed but processing of the

Issuer Script failure indicator
Command failed;
- Secure Messaging is required to perform the

command but not present.
Failure of a Script processing for a Command that

does not require secure message shall not impact the
indicator. On subsequent transactions, this indicator
may be reset during Completion.
15.2 Terminal Data
The table below specifies the terminal data used during Issuer-to-Card script
processing.
Table 43: Issuer-to-Card Script Processing - Terminal Data
The data element records results of the issuer Script

Issuer script results processing. The results shall be included in the
clearing message and the next online authorization.

TVR includes two indicator bits related to Script:
- Issuer script failed before the final GENERATE

Application Cryptogram Command;
Terminal Validation Results (TVR) - Issuer script failed after the final GENERATE
UnionPay only supports issuer script processing after

the final GENERATE Application Cryptogram
Command.
TSI includes the tag that indicates issuer script

Transaction Status Information (TSI)
processing was performed.
15.3 Key Management during Issuer Script Processing
Keys in issuer script operations include Master Message Authentication key and
Master Message Encryption key.
For details, please refer to the UnionPay Integrated Circuit Card Specifications -
Basic Specifications Part4: Debit/Credit Application Security Specification.
Figure 21 illustrates the generation and application of Master Message

Authentication Code (MAC) key.

Issuer starts Issuer generates MAC MDK is

MAC DEA mater stored in the issuer
DEA key (MAC authorization system
MDK)
PAN and PAN

sequence No.
Use MAC MDK,

PAN and PAN
Personalization sequence No. to PAN and PAN
generate MAC UDK sequence No.
and write it into the ATC
card
ATC
Issuer authentication system
- Use MAC MDK, PAN and PAN
sequence No. to calculate MAC UDK;
In transaction The card uses MAC - Use MAC UDK and ATC to calculate
UDK to generate MAC session key;
MAC session key - Generate Script Command MAC.
The card uses MAC

session key to verify Authorization response
the MAC from the Script command with MAC
issuer authorization
system
Figure 21: Generation and Use of MAC Key
The figure below illustrates the generation and use of Master data Encipherment
DEA key.
Issuer starts Issuer generates data ENC MDK is stored in

encryption DEA mater the issuer authorization
DEA key (ENC MDK) system
PAN and PAN

sequence No.
Use ENC MDK, PAN

PAN and PAN
Personalization and PAN sequence No.
sequence No.
to generate ENC UDK
ATC
and write it into the
card
Issuer authentication system
ATC - Use ENC MDK, PAN and PAN sequence
No. to calculate ENC UDK;
- Use ENC UDK and ATC to calculate data
The card uses ENC encryption session key;
Transaction
UDK and ATC to - Use session key to encrypt data in the script
generate data command data field.
encryption session key
The card uses data

encryption session key
Authorization response,
to decrypt the
Script command with encryption data field
encrypted data in the
Command

Figure 22: Generation and Use of Secure Messaging Encrypted Key
15.4 Authorization Response Data
The table below specifies the issuer script data in the authorization response if
Issuer-to-Card Script Processing is to occur.
Table 44: Issuer-to-Card Script Processing - Online Response Data
UnionPay only supports issuer script template 2. Tag “72”

marks template 2. The template shall include issuer dedicated
Issuer script template
script data transmitted to the card after the 2nd GENERATE
it is a number used by the issuer to uniquely identify the issuer

Issuer script identifier
Script.
Each issuer script Command in the Script shall be in

Issuer script Command
BER-TLV format and shall start with tag “86”.
15.5 Command
The following functions are the ones that can be performed during Issuer-to-Card
script processing. It is recommended to use Issuer Script Command to process these
functions. For detailed encoding of the commands, please refer to Appendix B.
Except for CARD BLOCK Command, all the commands are applicable to the
current selected application.
APPLICATION BLOCK
If the issuer determines that the current application in use should be invalidated,
APPLICATION BLOCK function will be performed. The application block now
can be unblocked by the issuer subsequently.
APPLICATION BLOCK Command is used to block the application. After the

application is blocked, file status indicator related to the application shall indicate
that the application has been blocked. Even though the application is blocked,
internal data access to the card will keep valid. For a blocked application, the card
will return an AAC to the GENERATE Application Cryptogram Command.
If the application is blocked during transaction, the terminal and the card will allow
the transactions to be executed further until the Completion. However, for the
subsequent transactions, the card does not allow blocked applications to be selected
for Financial Transaction (the terminal may select a blocked application for

unblocking. Therefore, the card must respond an AAC to GENERATE AC

Command).
APPLICATION UNBLOCK
APPLICATION UNBLOCK unblocks the blocking status of an application.

APPLICATION UNBLOCK shall be performed on special devices as designated
by the issuer.
As APPLICATION UNBLOCK needs to be performed on special devices,

processing flow does not need normal authorization or processing rules of financial
transaction. After the card responds an AAC to the 1st GENERATE AC Command,
the device should be able to send the transaction online, regardless of whether the
Issuer authentication is executed, the card should be able to process
APPLICATION UNBLOCK command properly. Neither card risk management
nor terminal risk management must be performed. The 2nd GENERATE AC
Command is not needed also. (If the card unblocks an application before the 2nd
GENERATE AC Command is sent for certain reasons, the device shall process the
responded cryptogram as AAC).
CARD BLOCK
CARD BLOCK Command is a post-issuance command. It makes all applications

on the card disable permanently.
CARD BLOCK Command makes all applications on the card invalid and makes
the card power-off. Unless a card is blocked, Payment System Environment (PSE)
shall always be valid and can be accessed.
If the card is blocked during transaction processing, the card and the terminal will
allow the transaction to proceed till Completion. A blocked card cannot be
unblocked with Issuer script Command or other commands. Therefore, the card is
essentially disabled. If the card is blocked, the PSE shall be invalid. The card will
respond “Function not supported” (SW1/2 = “6A81”) to SELECT Command. The
card will not allow any other form of application selection such as implicit
selection.
When the issuer decides to disable any functions of the card, CARD BLOCK can
be performed. Such as lost card or stolen card. After the card is blocked,
applications on the card cannot be unblocked.
The CARD BLOCK Command in issuer Script is used to realize the function of
blocking the card.
PIN CHANGE / UNBLOCK
PIN CHANGE / UNBLOCK Command is used to unblock the offline PIN or to

simultaneously block and change PIN value. The card can realize PIN unblock
through resetting PIN try times counter to the maximum value (PIN try limit).

 Unblocking the PIN
PIN CHANGE / UNBLOCK Command is performed successfully and PIN try

counter is reset to be PIN try limit.
 Change PIN value
If PIN value needs to be changed, PIN data shall be encrypted with symmetric
algorithm. For descriptions on algorithm, please refer to 18.6.3 Card Secure
Messaging. When PIN value is changed, the PIN try counter will be automatically
reset to PIN try limit.
PIN change must be performed under a secure environment under the issuer’s
control.
PUT DATA
The PUT DATA command allows specific primitive data objects in the card to be
updated. A data object can be updated with this command only if it has a tag
associated with it.
According to the Specification of this version, the following data can be changed
through PUT DATA Command. A proprietary internal file shall always be used for
these data elements:
 Upper limit of consecutive offline transaction (“9F59”);
 Lower limit of consecutive offline transaction (“9F58”);
 Consecutive offline transaction limit (international-country);
 Consecutive offline transaction limit (international-currency);
 Accumulated offline transaction amount limit;
 Accumulated offline transaction amount limit (dual currencies);
 Upper limit of accumulated offline transaction amount;
 Currency conversion factor.
Upper limit of consecutive offline transaction (“9F14”) and lower limit of

consecutive offline transaction (“9F23”) defined by UnionPay are stored in Short
File Identifier (SFI) 1-10. They can be changed through UPDATE RECORD
Command in Issuer script Command.
UPDATE RECORD
UPDATE RECORD Command is used to change a record of a file. The contents

changed are stored in the data field in UPDATE RECORD Command.

15.6 Processing
15.6.1 Authorization Response Message
Tag “72” in the authorization response message indicates after the 2nd GENERATE
AC Command, issuer script processing is to be performed. One Script can include
multiple commands.
Appendix B defines encoding of Issuer Script Command.
Commands that are used to change or reset card contents must be reported in
messages. Please refer to 15.6.3.
15.6.2 Card Script Processing
As the card cannot recognize whether the command is an Issuer script command or
any other command, the card cannot reject any command sent before the 2nd
GENERATE Application Cryptogram Command.
15.6.4 Result Indicator describes the UnionPay dedicated indicator bit in the card
which records the status of issuer script command received after the 2nd
GENERATE AC Command.
The card shall not reject an Issuer script because Issuer authentication is not
performed. If Issuer authentication is performed but failed, then the card shall reject
the Issuer script command. In this situation, the recommended response to an Issuer
script command is “6985”.
15.6.3 Card Secure Messaging
Before executing an Issuer script command, the card uses secure messaging to
authenticate the issuer. If Card receives Script Commands of secure messaging
checking failure, status code “6985” will be returned, while the subsequent Script
Command will not be executed. During script processing, issuer authentication
method which is described in the online processing is not performed.
The Security Specification describes the execution method of secure messaging
The basic purpose to use secure messaging is to guarantee the data confidentiality
and information Integrity and authenticate the issuer. Information Integrity and
issuer authentication can be based on MAC. Data confidentiality can be guaranteed
based on encrypted data, such as PIN encryption.
 Message Authentication (MACing) — Message authentication (MACing) is

used to authenticate whether the issuer is a legal party to send Issuer Script
Command and to guarantee that the command is not changed after it is sent
out.

MAC is calculated from all the data in the Command, including head of the
Command. Data encryption (if necessary) shall be performed before MAC is
generated.
 Data Confidentiality — Data encipherment is used to guarantee confidentiality

of plaintext data in the command. It is performed before MAC generating the
Command. Both the issuer and application in the card shall be aware of the
data encryption method.
For detailed on generation and data encryption of MAC, refer to Appendix C.
15.6.4 Resulting Indicators
The card uses the Issuer Script Command counter to record quantity of commands
with secure messaging received after the 2nd GENERATE AC Command.
When the card processes the commands received after the 2nd GENERATE AC
Command, the card shall set issuer Script failure indicator bit as “1” if any of the
following errors occurs:
 Secure messaging is required but not present;
 Secure messaging failed in verification;
 Secure messaging passed but the processing of command failed
Failure of card processing for a command that does not require secure messaging
shall not impact this indicator
15.6.5 Processing Flow
The figure below illustrates how the card processes each command during
Issuer-to-Card script Processing.

Card Terminal
The card
receives Script Command
Command sent
by the terminal
Secure
Secure Messaging
Messaging? NO required for the
Command? NO
YES
Increase Script
Command
counter by 1 Command
processing
Use MAC
UDK and
ATC to
generate MAC
session key
MAC
effective?
YES
YES
Use ENC UDK NO

and ATC to
generate data
encryption session
key
Encrypted
Data is
decrypted
Command Set Issuer Script

processing Failure indicator bit = 1
NO
Command
executed
successfully
?
Command response
YES The card returns the
command response.
Figure 23: Flow Chart for Issuer Script Processing
Online Processing
Online responses received by the terminal may include issuer script.
Completion
If the online responses received by the terminal include issuer script, Issuer-to-Card
script processing shall be performed after the Completion processing.

Card Action Analysis (Subsequent Transactions)
During card action analysis of the card’s next transaction:
 The card will set Bit 8 – 5 of Byte 4 in CVR as issuer Script Command
counter;
 If the issuer Script Processing failure indicator bit is “1”, the card will set
“Issuer script processing for the last transaction fails” bit in CVR as “1”.
Completion (Subsequent Transactions)
After an online transaction, if any of the following conditions is met, Issuer Script
failure indicator bit and issuer Script counter will be reset as “0”:
 Issuer authentication was successful;
 Issuer authentication was optional and not performed;
 Issuer authentication was not supported.

16 Card Records Transaction Details
During Card Risk Analysis and Completion, the card shall record transaction
details before deciding to approve the transaction and return TC,.
16.1 Transaction Detail Record File
Transaction detail record file is a circulating record file with a fixed length. The
record format excludes application elementary data template (tag ‘70’). Short File
Identifier and record quantity of the record file are specified in the data element of
log entry (tag ‘9F4D’). Short File Identifier of transaction detail record file must be
within the scope of 11-30. The recommendation under This Specification is 11.
Log entry data element is returned in the issuer dedicated data from the card when
application is selected.
Record contents are decided by the log format (tag ‘9F4F’). Range of log format is
a series of tags and lengths of data objects of the log contents. The terminal obtains
log format data element through Get Data Command so that the contents to be
recorded in transaction detail record file is clear.
Log format and transaction log records can still be accessed even after the
application is blocked.
In order to read transaction log information, specific devices shall use the following
procedures:
 To perform application selection and obtain log entry data element from issuer
custom data. If log entry data element does not exist, the application will not
support transaction log function.
 To send a GET DATA command to obtain log format data element;
 To send a READ RECORD command to read transaction log records. It is free

to read authority of transaction detail record file but writing authority is
restricted as that is controlled by the card operation system.
16.2 UnionPay Suggestions
Log entry data element content has a tag of ’0B0A’. SFI of the transaction detail
files is 11. The quantity of records is 10.
Log format data element specifies the tags and lengths of data objects defined in the
table below.
Table 45: Contents of Transaction Detail Record File

Data Tag Length (Byte)
Terminal date 9A 3
Transaction time 9F21 3
Authorized amount 9F02 6
Other amounts 9F03 6
Terminal country code 9F1A 2
Transaction currency code 5F2A 2
Merchant name 9F4E 20
Terminal type 9C 1
Application transaction counter (ATC) 9F36 2
During application selection, the issuer dedicated data in response information of

the card to SELECT command includes log entry data element. The card also
specifies data that shall be input by the terminal in PDOL data element. Then the
terminal shall transmit terminal data elements designated in PDOL to the card in
the next GET PROCESSING OPTIONS command and the card will store the data.
After the card makes the decision of accepting the transaction through card risk
management or transaction completion, it will store transaction detail contents
specified in log format together with the terminal data elements above into the
Transaction Details. If the stipulated Data Element in transaction log format does
not exist, ‘00’ will be filled, the length of the padding filed should comply to the
length requirement defined in the corresponding length field.
The terminal can transmit the terminal data element in transaction details through
PDOL or CDOL to the card.
If the issuer does not establish Transaction Detail files when it issues the card, but
log entry data element is included in the response to application selection, then the
card still cannot record transaction details.
The card can only record transaction details when the card responds TC to the last
GENERATE AC Command. For one transaction, transaction details can only be
recorded at most once.

17 Contact Low-value payment function based on debit/credit application
17.1 Technical Require Additional data elements
17.1.1 Add Data Elements
For added data elements on the basis of debit/credit application, please refer to table 46: Card
Data Elements and table 47: Terminal Data Elements.
Table 46 Card data elements
Name of data element Acquisition Tag Length Format
Electronic Cash Balance (EC Balance) Get Data 9F79 6 n 12
EC Balance Limit Get Data 9F77 6 n 12
EC Issuer Authorization Code Read Record 9F74 6 a
EC Single Transaction Limit Get Data 9F78 6 n 12
EC Reset Threshold Get Data 9F6D 6 n 12
Load log Entry Select DF4D 2 b 16
Load Log Format Get Data DF4F var. b
——Electronic Cash Balance：This data element saves the available amount of the total amount
for offline transactions. For each successful Low-value payment transaction, the
corresponding authorized amount will be subtracted. Once the authorized amount exceeds
the Electronic Cash Balance, the transaction will be processed according to the standard
debit/credit.
——Electronic Cash Balance Limit: it means the maximum cumulative limit that the cardholder
may use for offline transactions in the electronic cash application, or the upper limit that may be
reached by recharging the card. The Issuer may revise the upper limit;
——Electronic Cash Issuer Authorization Code: the code on the card used for marking the approved
electronic cash transaction. In an offline approved transaction, the code is stored in the
authorization code of clearing message, in the format of “ECCxxx” of which “xxx” stands
for the number defined by the Issuer;

——Electronic Cash Single Transaction Limit: the upper limit of the authorized amount for one
single electronic cash transaction on a card, for controlling the risk of single electronic cash
transaction. It is written by the Issuer during personalization and can be reset by the Issuer;
——Electronic Cash Reset Threshold: lower available balance limit to activate the card to perform
automatic load. When the offline available balance on a card is lower than the threshold, the
card should request online processing and initiate loading automatically.
Table 47 Terminal data elements
Name of the element Tag Length Format
EC Terminal Support Indicator 9F7A 1 b
EC Terminal Transaction Limit 9F7B 6 n 12
——Electronic Cash Terminal Support Indicator: Indicating that the terminal to support
electronic cash processing
——Electronic Cash Terminal Transaction Limit: the terminal uses the data element (if any) to
decide whether the transaction is performed in the electronic cash mode. If the data element is
present, the transaction is not an electronic cash transaction when the authorized amount is
higher than that limit; if the data element is absent, the transaction is not an electronic cash
transaction when the authorized amount is higher than the terminal floor limit.
17.1.2 Card Offline Data Authentication
For the description of Card offline data authentication, please refer to Part IV.
The Issuer should adopt the powerful CAM mechanism to prevent the risk of offline fraud.
For instance, the card may be set to allow the offline transaction only under the
circumstance of executing Dynamic Data Authentication (DDA) or Combined DDA/AC
Generation (CDA). AIP shall be contained in SDA signature.
17.1.3 Principles of Cardholder Verification Method
It is recommended to set CVM list based on the following principles:
——To facilitate offline processing, online PIN should not be set as preferred CVM.
17.1.4 Transaction Log
The low-value payment function adopts the same method as debit/credit to record
transaction log. Please refer to section 16.

17.1.5 Currency Conversion
Electronic Cash Balance refers to the available value for offline transactions which is
calculated in terms of application currency. Low-value payment function does not permit
supporting currency conversion either through the card or the terminal because Electronic
Cash Balance must reflect the available amount for transactions accurately, however the
currency conversion may lead to the fact that an inaccurate amount of Electronic Cash
Balance may be saved in the card.
17.1.6 Data Element Usage
As described in section 17.1.1, three card data elements which are Electronic Cash Balance,
Electronic Cash Balance Limit and Electronic Cash Single Transaction Limit, are added in
the low-value payment function, for controlling the offline risk of the Issuer.
The Issuer may change the card behavior in accordance with the threshold value of the
offline counter. Card risk management uses these thresholds according to the following
principles:
——If the authorized amount is lower than the Electronic Cash Balance and the Electronic
Cash Single Transaction Limit, the card should approve offline transaction;
——When the authorized amount exceeds the Electronic Cash Balance or the Electronic
Cash Single Transaction Limit, the standard debit/credit flow should be processed.
The Issuer may grant the online authorization to a transaction according to the primary
account balance of the cardholder. The Issuer may conduct loading by the way of script to
adjust the value of Electronic Cash Balance, and the script will be processed by Issuer as
standard debit/credit process.
17.1.7 Load Log
The Load Log is a separate Log from the Transaction Log, recorded and stored by the card.
When the Electronic Cash Balance (9F79) on the card is successfully rewritten by the Put
Data Command, one record will be recorded into Load log by Card.
The recording and cyclic covering of the Transaction Log should not affect the Load Log
and vice versa.
The Load Log recording and Put Data Command should be successfully performed in the
same time. If one of them fails, another action should be also failed.
The Load Log record document is a circulating record file with a fixed length. Its SFI and
Record Number are stipulated by the Load log Entry Data Element (Tag "DF4D"). The SFI
value of the Load Log record document should be between 11-30, and should not repeat
the other documents defined in this specification. UnionPay Integrated Circuit Card
Specifications - Basic Specifications recommends the SFI value of the Load Log to be 12,
and the Load Log entry data element should come back from BF0C template of the FCI of
the ADF in the card, when selecting its application.

The content of the Load Log is defined in 17.5.2 of this section.
Load Log Format (Tag "DF4F") and Load Log record should still be available for visit
after locking the applications.
Ways of reading the Load Log include reading one by one and reading disposable all Load
Log messages: the cardholder and the Issuer may inquire Loading details using one-by-one
reading; one-off reading of all Load messages may be applicable on automatic facilities, or
the acquisition of Issuer counter of the entire Load Log protected by MAC, providing
reference when there is an account error. The two ways of reading use the following
procedures:
One-by-one reading:
——Executing application selection: To get Load Log Entry Data element from the
custom data of FCI's Issuer. If the Load Log entry data element does not exist, it means
that the application does not support the Load Log Function.
——Send a Get Data command to get Load Log format data element;
——Send Read Record (P1 = Record Number) command to read Load Log record
One-off reading of all Load Log messages:
——Executing applicable choice, to get Load Log data element from the FCI Issuer
custom data. If the Load Log data element does not exist, it means that the application does
not support the function of Load Log.
——Send a Read Record command (P1=00) to read the Load Log record.
There is no restriction on reading permission of the Load Log record. Writing permission
is not enable and is controlled by the card operational system.
17.2 Definition of Balance
The term “Balance" is not used to indicate that a card contains any currency. It indicates
the maximum offline payable amount promised by the Issuer to a merchant. In addition to
Electronic Cash Balance, there may be other balances with different values:
—— Primary account balance: It refers to upper payable limit for a debit/credit

transaction and it is the available balance in the primary account;
The Issuer should provide the corresponding training for cardholders to make them aware
that different available balances for purchases may be caused under different
circumstances.
17.3 Transaction Processing
When one low-value payment transaction is to be performed, the following described is

unique processing related to the electronic cash transaction, please refer to the processing
procedures in Part IV of This Specifications for those are not listed below

17.3.1 Application Selection
The terminal sends SELECT command to select the application, and the card returns the
file control (FCI) information, including PDOL which contains Electronic Cash Terminal
Support Indicator, authorized amount and transaction currency code.
17.3.2 Application Initialization
If the following conditions are satisfied:
——The terminal supports the low-value payment transaction;
——The authorized amount is lower than Electronic Cash Terminal Transaction Limit, or
lower than the terminal floor limit if the terminal does not contain the independent
Electronic Cash Terminal Transaction Limit;
——The terminal transaction is a purchase transaction.
As a result, the terminal will provide in GPO command Electronic Cash Terminal Support
 Indicator (set as “1”).
When receiving GPO command, the card will take the transaction as a low-value payment
transaction if the following conditions are met:
——the command includes the electronic cash terminal support indicator (set as "1");
——the transaction currency code matches with the application currency code;
——the authorized amount should not exceed the electronic cash balance;
——the authorized amount should not exceed the electronic cash single transaction limit;
——the authentication error indicator of the Issuer is "0";
——the script processing error indicator of the last online transaction of the Issuer is "0";
——the PIN Try Counter is not "0".
If one of the above criteria is not satisfied, the transaction is not considered as a low-value
payment transaction.
If the transaction is taken as a low-value payment transaction, the card should:
——Mark this transaction as a low-value payment transaction;
——Return GPO response data AIP and AFL. AIP refers to the functions supported by
low-value payment transaction. AFL indicates the specific data of low-value payment
transaction -- the location of the electronic cash Issuer authorization code.
If the transaction is not a low-value payment transaction, the card returns non-low-value
payment (debit/credit) AIP and AFL in the response to GPO (not returning Electronic Cash

Issuer Authorization Code), the terminal will process this transaction as standard
debit/credit transaction.
If the terminal receives the AIP and AFL, and the electronic cash Issuer authorization code
exists, it reads the following data with the GET DATA command:
——Electronic Cash Balance
——Electronic Cash Reset Threshold
If the terminal does not receive the AIP and AFL, the transaction will be terminated.
17.3.3 Terminal Risk Management
The terminal does not perform the floor limit, random transaction selection and velocity
checking.
17.3.4 Terminal Action Analysis
The terminal reads data from the AFL that returns from the card, and compares the
difference between Electronic Cash balance and the authorized amount with the Electronic
Cash Reset Threshold; meanwhile, it performs the terminal action analysis in combination
with the terminal capacity.
——If the value from Electronic Cash Balance minus authorized amount is higher than or
equal to Electronic Cash Reset Threshold, it will request the offline approval from the card
to continue the low-value payment transaction;
——If the value from Electronic Cash Balance minus authorized amount is lower than
Electronic Cash Reset Threshold, it will determine the following decisions according to the
terminal capacity:
 If the terminal has an online capacity, it will request the online processing and require
the cardholder to enter an online PIN; and this transaction requests to the Issuer and get the
online authorization with updating the Electronic Cash Balance;
 If the terminal does not have an online capacity, the terminal will request offline
approval, so that this transaction may be completed with an offline mode.
 If the terminal fails during an online processing, the terminal and the card will
continue performing the standard debit/credit transaction.
17.3.5 Card Action Analysis
For a low-value payment transaction which is designated at the stage of application

initialization, the card should execute the following steps:
——If the terminal declines the transaction offline (requests an AAC), the card will return
AAC in the response to the command of GENERATE AC;

— — Skip checking the uncompleted online authorization, last transaction issuer

authentication failure checking, last online transaction script processing checking, new
card checking, offline PIN try counters checking, various velocity checking, perform the
last transaction SDA failure checking and last transaction DDA failure checking;
——If the terminal requests online transaction, the card will return ARQC in the response
to the GENERATE AC command;
——If the terminal requests offline approval, the card should check whether the tag
provided by the terminal in the GENERATE AC command matches the tag provided by
the GPO command (these tags exclude terminal verification result '95', transaction status
message '9B' and the unpredictable number '9F37' but include others besides transaction
currency code '5F2A', authorized amount '9F02', but does not include). If the checking
results are matched with each other, the card will deduct the authorized amount from
Electronic Cash balance and return TC in response to the GENERATE AC command,
otherwise the card will return AAC in response to GENERATE AC command;
——Return updated Electronic Cash Balance in Issuer Defined Data (IDD) (please see
Table 3) of issuer application data (Tag 9F10)..
——The result of electronic cash transaction will not affect the values of various counters
in the standard debit/credit (except for ATC).
17.3.6 End of Transaction
In the transaction completion, Both Electronic Cash Balance is shown to the cardholder by
the terminal and printed on the receipt should be obtained from the IDD of the Issuer
applicable data (9F10) that the card returns in response to the GAC data. Please refer to
Table 48 for the format of IDD. If Electronic Cash Balance is not included in the IDD, the
terminal should follow the procedures in the appendix H which gets Electronic Cash
Balance.
After completing the transaction, the terminal will collect the transaction data and send the
transaction details to the Acquirer on the same day to perform the subsequent clearing. The
terminal should provide Electronic Cash Issuer Authorization Code in the authorization
code of clearing message. The Electronic Cash Balance that the card sends to the terminal
may be printed on the transaction receipt.
When receiving the transaction data for clearing, the Issuer may identify whether it is a
low-value payment transaction. If yes, it will deduct the corresponding transaction amount
from the electronic cash account (rather than the cardholder primary account).
Table 48 Issuer-defined Data (IDD)
IDD Selection Length (Byte) ID Amount Field MAC Byte Count

Electronic Cash Value of Tag "9F79"

10 0x01 4
Balance Available (Low 5-bit byte)
The data for verification number calculation include 2-byte application transaction counter,
available Electronic Cash Balance and 1-byte 0x00 bit padding rightmost.
A 4-byte verification number is obtained by calculating the session key from MAC UDK
derivation. The methods of key derivation and MAC calculation are defined in Part VII of
This Specifications.
The Issuer-Defined Data (IDD) is determined by the issuer during the card personalization
processing, for definition of IDD and other definitions, please refer to Part V Appendix D.
Table 49 MAC Calculation
ID Data Block Length Elements
ATC 2 bytes
0x01 8-bit bytes Electronic Cash Balance available Low 5-bit bytes
Padding 1 byte

17.4 Transaction Flow Chart
Terminal Card
Returns PDOL, requesting EC
Select all AID to Terminal Supporting Indicator,
Select Command
be used Authorized Amount and Transaction
Select Response
Currency Code
Transaction
Type =
Purchase? EC Terminal Supporting
Indicator is ‘1’?
Yes No
Yes
Terminal
No
Supports EC? Transaction Currency Code=
Application Currency Code? No
Yes
EC Terminal Floor Terminal Floor Yes

No GPO Command
No
Limit present? Limit present?
Authorized Amount <= EC
Yes No
Yes Available Amount?
Authorized Authorized Yes

amount < EC amount<Termina No
Terminal Floor l Floor Limit?
Authorized Amount <= EC
Limit No
Set EC Supporting Single Transaction Limit?
No
Indicator as 0
Yes Yes
Yes
Sends GPO command including
Sets EC Terminal
Terminal Supporting Indicator, Issuer Authentication
Supporting No
Authorized Amount and Failure Indicator = 0
Indicator as 1 No
Transaction Currency code
Receives returned Yes
value of GPO
Issuer Script Processing
Failure Indicator = 0 No
Receives
AFL&AIP?
No Yes
Yes
Terminal receives
record on card PIN Try Counter=0 No
Yes
EC Issuer
authorization GPO Response
code present? Indicates
transaction as EC
Yes
Obtain EA Balance No
and EA Reset Value Terminal AIP = EC AIP
by GET DATA terminates AFL = EC AFL
transaction (EC AFL contains AIP = CUPIC AIP
file No. containing AFL = CUPIC AFL
Offline data EC Issuer Auth
authentication Code)
Terminal Risk
Management
Figure 24: Transaction Flowchart (1)

Terminal Card
NO
Is the transaction
Terminal Action Analysis as EC transaction?
Standard CUPIC
TC Yes flow processed
First GENERATE Card Risk Management

AC Command processed, application
EC Available Amount – cryptogram generated
Authorized Amount < EC TC ARQC
ARQC Reset Value? ACC
ACC
No
Yes Deducts
Returns AAC in Returns ARQC in
Authorized
GENERATE AC GENERATE AC
Terminal supports Amount from EC
Response Response
online processing Available Amount
Yes No
Cryptogram Returns TC in
Cryptogram Type Cryptogram Type GENERATE AC
Type requested
requested is ARQC requested is ACC Response
is TC
Returns updated
EC Balance in IDD
of ‘9F10’
Terminal completes
GENERATE AC GENERATE AC
standard transaction
Response Response
processing flow
*: The terminal continues to process the transaction according to debit/credit application

flow.
Figure 25: Transaction Flowchart (2)
17.5 Card Command
This chapter describes in details the common commands are used to control the financial
IC card with low-value payment function:
——Electronic Cash Balance Inquiry;
——Transaction Log Inquiry;
——Command of obtaining transaction log formats;
——Command of updating electronic cash parameters.
17.5.1 Electronic Cash Balance Inquiry
The command regarding Electronic Cash Balance allows the terminal to read the available
offline transactions amount from the card directly. The Electronic Cash Balance is
obtained with the GET DATA command.
Please refer to Table 50 and Table 51 for the data format of the command and its response.
Table 50 GET DATA command for Electronic Cash Balance Inquiry

Byte Value Description
CLA “80”
INS “CA”
P1 “9F”
"9F79" is the tag for Electronic Cash Balance data
element
P2 “79”
LC N/A
Data N/A
Le “00”
Table 51 Electronic Cash Balance Inquiry responses
Tag (T) “9F79”
Length (L) “06” 6 bytes
Data (V) EC Balance Represented in the currency defined in the application
Status information, please see chapter 2 of UnionPay Integrated

SW1/SW2
Circuit Card Specifications - Basic Specifications
Electronic Cash Balance should be represented in the currency defined in the application.
17.5.2 Transaction Log Inquiry
The command regarding the transaction log allows the terminal to access the records stored
in the card transaction log, and such records should be read with the READ RECORD
command.
Please refer to Table 52 and Table 53 for the data format of that command.
Table 52 READ RECORD command

CLA “00”
INS “B2”
P1 Record Number
Please see the structure table in P1 and P2
P2 Reference Control Parameter
LC Does not exist
Data Does not exist
Le “00”
Please refer to Table 53 for the values of P1 and P2 parameter fields in the command of
READ RECORD.
Table 53 Structure Table of P1 and P2
Byte Digit Meaning Value
00: to acquire all the record from the Load Log in the card
on one go, and the record content it returns to goes through
MAC to ensure record entirety.
P1 1~8 Record Number
Record Number: From 1 to the maximum Record Number
supported by the application (the minimum is 10). The actual
size is defined in the FCI.
Recommended value for Transaction Log is 0x0B

8~4 SFI
Recommended value for Load Log is 0x0C
P1 is the Record
3 1
P2 Number
2 Not used 0
1 Not used 0

The sequence of each data element in the Transaction Log is defined by Transaction Log
format (9F4F). The recommended value of the format can be detected in Table 45. The
sequence of each data element in the Load Log is defined in Table 54. When recording on
the Load Log, the Basic Data Templates (Tag "70") should not be included, the tag and
length of the data element are also not required, only the value is needed to be recorded.
The Transaction Log format (DF4F) should be retrieved through GET DATA command.
No. 1-4 in Table 54 are the fixed content in the Load Log, and no. 5 is the variable content
in the Load Log but that value can be defined by the issuer. For recommended value,
please refer to Table 55.
Table 54 Load Log Content List
No. Data Length (Byte)
1 P1 value of PUT DATA command (Value at 0x9F or 0xDF) 1
2 P2 value of PUT DATA command (Value at 0x79) 1
3 Value of 9F79 or DF79 before PUT DATA amendment 6
4 Value of 9F79 or DF79 after PUT DATA amendment 6
5 Value of Data Element defined in the Load Log format (DF4F) (See var.
Table 55)
Remark: For definition of DF79 in Table 54, please refer to "Low-value Payment
Specification Based on Debit/Credit Application)
Table 55 Load Log Format (DF4F) recommended value
Tag Data Length (Byte)
9A Transaction Date 3
9F21 Transaction Time 3
9F1A Terminal Country Code 2
9F4E Name of Business 20

9F36 Application Transaction Counter (ATC) 2
The latest transaction is stored in record 1, the second latest transaction is stored in record
2, and so on with the same rule.
If the terminal tries to read an empty record, the card returns an error (SW1SW2 = "6A83").
Empty record may be reflected in the following situations:
——There is no transaction record in the Log (in case it is a new issued card);
——P1 is larger than the maximum record number (the maximum record number refers to
the maximum number of records in the current card transaction detail record).
——In order to read full contents in the transaction log, the terminal should start from
Record 1 to execute all READ RECORD commands until the card responds to
SW1SW2=“6A83”, it indicates that the last item of log has been read1.
17.5.3 Command of Obtaining Transaction Log formats
In order to correctly explain the data in the transaction log, the terminal needs to know its
data formats. The formats are defined in File Control Information (FCI). The transaction
log formats are read by using the commands in Table 56.
Table 56 Acquire Transaction Log format GET DATA Command
CLA “80”
INS “CA”
P1 “9F”
"9F4F" is the data tag for log formats
P2 “4F”
LC Does not exist
Data Does not exist
Le “00”
1
The storage size of the transaction log is depended on the issuer.

Response data belong to the transaction log, and the log formats will be encoded in a
manner similar to DOL (data object list). Please refer to Table 9 for the data element
format.
17.5.4 Update Electronic Cash Parameter Command
The Electronic Cash Parameters on the card can be updated by the PUT DATA command
in Chapter 2. The Issuer host should create and send such command in the form of a script
during the authorization response. There are four card electronic cash parameters that can
be updated through the script command which are Electronic Cash Balance, Electronic
Cash Balance Limit, Electronic Cash Single Transaction Limit and Electronic Cash Reset
Threshold. Please update the Electronic Cash parameters by using the command format in
Table 57 and58
Table 57 PUT DATA Command for Updating Electronic Cash Balance.
CLA “04”
INS “DA”
P1
P1 and P2 are the tags of EC parameters
P2
LC “0A”
Data Value New value of EC parameters
Le “00”
Table 58 P1 and P2 values of Electronic Cash Parameters
Name of Data Element P1 P2
EC Balance 9F 79
EC Balance Limit 9F 77
EC Single Transaction Limit 9F 78

EC Reset Threshold 9F 6D
The response status code for successful update is SW1SW2="9000", the status of other
possible errors are defined in the regulations in Chapter 2.

Appendix A Definition of Card and Issuer Data Elements
A.1 Card and Issuer Data Elements Descriptions
Table A.1 lists the card and issuer data elements in This Specification, including
format (F), tag (T) and length (L).
Formats supported include:
 n (numeric);
 cn (compress numeric);
 b (binary);
 an (alphanumeric);
 ans (alphanumeric special).
If the defined length exceeds actual length of the data but not all the bits are
occupied, the remaining bits shall be applied with the following rules:
 Data element in format n shall be right-justified and padded with leading

hexadecimal zeros;
 Data element in format cn shall be left-justified and padded with trailing

hexadecimal Fs;
 Data element in format an shall be left-justified and padded with trailing

hexadecimal zeros;
 Data element in format ans shall be left-justified and padded with trailing
hexadecimal zeros.
Column “Requirement” specifies the requirement for data elements:
 M (mandatory): The data element must be present and be provided to the

terminal. If the terminal cannot read the data during the process of Read
Application Data, it will terminate the transaction.
 R (Required): The data element must be present. The terminal will not check
the data during the process of Read Application Data.
 C (Conditional): The data element must be present under certain conditions.
 O (Optional): The data element is optional.
 When data is moved from one entity to another (for example, card to terminal),
it shall always be passed in order from high order to low order, regardless of
how it is internally stored. The same rules apply when concatenating data.
Table A.1: Card and Issuer Data Element descriptions

Name (format;
Requirement Descriptions Value
tag; length)
Byte 1: Length indicator ( 03)
Byte 2:
bits 8–7:
00 = 2nd GENERATE AC
returns AAC;
01 = 2nd GENERATE AC
returns TC;
10 = 2nd GENERATE AC is
not requested.
11 = RFU
bits 6–5:
00 = 1st GENERATE AC
returns AAC;
Card UnionPay dedicated
Verification data. 01 = 1st GENERATE AC
Results Returns TC;
It indicates the exception
(CVR) conditions that occurred 10 = 1st GENERATE AC
M in the current and returns ARQC;
F: b 32 previous transactions. It
11 = Cannot return 11;
T: – is returned to the
terminal in the Issuer bit 4: 1 = Issuer
L: 4. Application Data. authentication performed
and failed;
bit 3: 1 = offline PIN is

performed;
bit 2: 1 = offline PIN

verification fails;
bit 1: 1 = Cannot go online
Byte 3:
bit 8: 1 = The last online

transaction is not completed;
bit 7: 1 = PIN Try Limit

exceeded;
bit 6: 1 = Exceeded Velocity

check counters;

Name (format;
tag; length)
bit 5: 1 = New card;
bit 4: 1 = Issuer
authentication for the last
online transaction fails;
bit 3: 1 = After online

authorization, issuer
authentication is not
performed;
bit 2: 1 = The card blocks

application as PIN Try Limit
exceeded;
bit 1: 1 = The transaction

declined offline as SDA for
the last transaction failed.
Byte 4:
bits 8–5: number of Issuer

script Commands received
after the 2nd GENERATE AC
Command containing
securing messaging
processed on last transaction;
bit 4: 1 = Issuer script

processing failed on the last
transaction;
bit 3: 1 = The transaction is

declined as DDA for the last
transaction failed;
bit 2: 1 = DDA is executed;
bit 1: RFU (0).
Bytes 2-4 are reset to zero

during application
initialization.
Dynamic Data UnionPay dedicated

Authentication C data. bit 1: 1 = Offline DDA for the
(DDA) Failure last transaction failed and the
If DDA is It indicates whether
indicator bit transaction is declined
supported. offline DDA failed on
offline.
F: b 1 last transaction when the
last transaction is

Name (format;
tag; length)
T: – declined offline
L: –
Consecutive
Offline UnionPay dedicated data
Transaction C element.
Counter The initial value is 0. For
If velocity It records the times of each time of completing an
(international-c
check is to be offline transactions international-currency offline
urrency)
performed on without using the transaction, it is increased by
F: b 8 international - designated application 1.
currency currency since the last
T: –
online transaction.
L: 1
Consecutive
offline
UnionPay dedicated data
transaction C
element. The initial value is 0. For
counter
If velocity each time of completing
(international-c It records the times of
check is to be international-country offline
ountry) offline transactions
performed on transaction, it shall be
performed beyond the
F: b 8 international - increased by 1.
issuer’s country since the
country
T: – last online transaction.
L: 1
UnionPay dedicated
Cryptogram
data.
Version Number
It indicates version of UnionPay specifies that
F: n2 R cryptogram version number is
the algorithm used to
T: – generate the cryptogram. 01 (’01’).
It is transmitted in the
L: 1
issuer application data.
UnionPay dedicated
Accumulated C The initial value is 0. It adds
data.
offline the authorized amounts for
transaction If velocity It records the each completed offline
amount check on accumulated offline transaction in the application
accumulated transaction amount in the designated currency. Reset to
F: n 12 amount is to be application dedicated zero after certain online
T: – performed. currency since the last transactions.
completed online

Name (format;
tag; length)
L: 6 transaction
UnionPay dedicated
Accumulated
C data. The initial value is 0. It adds
offline
transaction If velocity It records the the authorized amounts for
amount (dual check on accumulated offline each completed offline
currencies) accumulated transaction amount in the transaction in the application
amount (dual application designated designated currency and the
F: n 12 second application currency.
currencies) is currency and the second
T: – to be application currency Reset to zero after certain
performed. since the last completed online transactions.
L: 6
online transaction
UnionPay dedicated
Message
data.
Authentication Message Authentication
Code(MAC) C Double length Message Code(MAC) DEA key
DEA key Authentication Code
If PIN F: b 128
(MAC) key, 16bytes. It
F: b 128 modification is
is used to calculate MAC T: -
performed
T: - when secure massaging
L: 16
is required by issuer
L: 16
script.
UnionPay dedicated
data.
It is used to identify to
Derivation key the issuer the appropriate
index (DKI) issuer’s derivation key to
derive the card’s unique It is assigned by the issuer.
F: b 8 O DEA keys for online If it does not present, the
T: – card and issuer default value is zero.
authentication. (The DKI
L: 1 is not used by the card).
It is returned to the
terminal in the issuer
application data.
Dynamic Data C UnionPay dedicated bit 1: 1 = Offline DDA for the

Authentication data. last transaction failed and the
(DDA) Failure If DDA is transaction is declined
supported. It indicates whether
indicator bit offline.
offline DDA failed on

Name (format;
tag; length)
F: b 1 last transaction when the

last transaction is
T: –
declined offline
L: –
It is the dynamic data

generated or stored by
IC Card IC card. It is transmitted
Dynamic Data to the terminal in the
C Signed Dynamic
F: – Application Data. It is
If DDA is
T: – supported. used by the terminal to
prove that offline
L: var. Dynamic Data
Authentication has been
performed.
It is the private key part

C of the IC card public key
IC Card
pair. It is used for offline
Private Key If DDA is
Dynamic Data
supported.
F: b Authentication. There
If used for are two forms: modules
T: – Offline and secret exponent or
Enciphered and Chinese Remainder
L: NIC
PIN Theorem coefficients
(CRT).
bits 4–1: number of Script

UnionPay dedicated
Commands received after the
Issuer Script data.
2nd GENERATE Application
Command
It indicates the number Cryptogram Command using
Counter C
of Issuer script secure messaging processed
F: b 4 If issuer script Commands containing by the card during the
is supported. securing messaging transaction.
T: –
processed by the card
A value ‘F’ indicates that
L: – during the last
there are 15 or more Issuer
transaction.
script Commands.
Issuer Script C UnionPay dedicated

bit 1: Issuer script processing
Failure If issuer script data.
failed on the last transaction.
Indicator is supported. It indicates whether

Name (format;
tag; length)
F: b 1 issuer script processing

failed on the last
T: –
transaction
L: –
UnionPay dedicated
Message
data.
Authentication
C
Code(MAC) Double length Message
DEA key If issuer script Authentication Code
using secure (MAC) key, 16bytes. It
F: b 128
messaging is is used to calculate MAC
T: - supported when secure massaging
is required by issuer
L: 16
script.
Offline Decline UnionPay dedicated

C data. During the
Requested by
Card Indicator If card risk transaction processing, it
management indicates that internal
F: b 1 card processes have
check can
T: – generate a indicated that the
decline transaction should be
L: – declined offline.
Online
C UnionPay dedicated bit 1: 1 = Online
Authorization
data. authorization is required for
Indicator If the card
supports issuer It indicates if the card the current or previous
F: b 1 transaction, but online
authentication requested an ARQC and
T: – or issuer script the terminal was not authorization cannot be
processing completed. completed.
L: –
UnionPay dedicated
Online data.
Requested by
Indicator used during
card indicator
transaction processing to
F: b 1 R indicate that internal
card processes have
T: –
indicated that the
L: – transaction should be
processed online

Name (format;
tag; length)
UnionPay dedicated
PIN Try Limit
data.
C
F: b 8
It is the number of
If offline PIN is
T: – consecutive incorrect
supported.
PIN tries allowed by the
L: 1
issuer.
Proprietary
Application
Identifier It is part of AID which
Extension (PIX) identifies the Application
R Provider’s specific
F: b application according to
T: – ISO/IEC 7816-5.
L: 0–11
Offline PIN UnionPay dedicated

C data.
F: b
If offline PIN is It is written to the card
T: –
supported. by the issuer during card
L: 8 personalization.
Registered
Application
Provider
It is part of AID which
Identifier (RID)
identifies the Application
R
F: b Provider according to
ISO/IEC 7816-5.
T: –
L: 5
Static Data
UnionPay dedicated
Authentication
data.
(SDA) Failure
C bit 1: 1 = Offline SDA for the
Indicator It indicates whether failed on last transaction
If SDA is offline SDA failed on the and the transaction was
F: b 1
supported. last transaction when the declined
T: – transaction was declined
offline
L: –

Name (format;
tag; length)
UnionPay dedicated
data.
Application
Cryptogram It is a double length
(AC) key application cryptogram
M key. It is 16 bits long. It
F: b 128
is used for online card
T: – authentication and online
issuer authentication,
L: 16
and Application
Cryptogram generation.
UnionPay
It is part of the issuer
Integrated
application data defined
Circuit Card
by UnionPay. It consists
Specifications -
of a length indicator,
Basic
derivation key index,
Specifications
cryptogram version
Discretionary R
number and Card
Data
Verification Results. It is
F: b 56 returned to the terminal
in GENERATE
T: – Application Cryptogram
response.
L: var 7 to 9
It indicates the
Application application in line with
Identifier (AID) ISO/IEC 7816-5. It
consists of Registered
F: b 40–128 R Application Provider
T: 4F Identifier (RID) and
Proprietary Application
L: 5–16 Identifier Extension
(PIX).
Mnemonic associated
Application tag R with AID. Used in
application selection.
F: ans 1–16 (According to
Application tag is
EMV, it will
T: 50 optional in the File
become
Control Information
L: 1–16 mandatory.)
(FCI) of an Application
Definition File (ADF)

Name (format;
tag; length)
and mandatory in an
ADF directory entry
Contains the data

elements of track 2
Track 2 according to ISO/IEC
Equivalent Data 7813. Excluding starting
sentinel, end sentinel and
F: b
LRC (VERIFY code). as
T: 57 follows:
L: var. up to 19 Primary Account

Number (PAN);
n, var. up to 19
Field Separator (“D”); Track 2 Equivalent data shall
1 M be stored in Short File
Expiration date Identifier 1 Record 1.
n4
(YYMM);
n3
Service code;
0 or n 5
PIN Verification Field;
n, var.
Discretionary Data
(defined by payment
system);
hex.
Pad with F if needed to
ensure whole bytes
Application
Primary
Account
Number(PAN)
Valid account No. of the
F: var. up to cn M
cardholder.
19
T: 5A
L: var. up to 10
Cardholder name,
Cardholder Notes: The value of this data
consistent with ISO/IEC
Name object can be Chinese
R 7813. If the cardholder
characters, and it may cause
F: ans 2–26 name is or shorter than
transaction rejections on a
26 bits, the tag 7FOB
T: 5F20 limited number of
shall not be used. The
international terminals
complete cardholder

Name (format;
tag; length)
L: 2–26 name shall be stored outside Mainland China.

under the tag.
Application
Expiration Date
F:n 6 Date after which the

YYMMDD M application in the card
expires
T: 5F24
L: 3
Application
Effective Date
F:n 6 Date from which the

YYMMDD O application in the card
may be used
T: 5F25
L: 3
Issuer Country
Code
C
F: n 3 It indicates country of
If Application the issuer according to
T: 5F28 Usage Control ISO3166.
L: 2 is present.
Preferred
Language It stores 1 to 4 languages
by priority. Each
F: an 2 O represented by 2
T: 5F2D alphabetical characters
according to ISO639.
L: 2–8
Service code Service Code as defined

on magnetic stripe track
F: n 3 O
1 and track 2 according
T: 5F30 to ISO/IEC 7813.

Name (format;
tag; length)
L: 2
Application
primary account
number
sequence It is used to indicate
number different applications
O
with the same PAN in
F: n 2 the card.
T: 5F34
L: 1
Issuer URL
F: ans It indicates the location

O of issuer’s library server
T: 5F50 on the Internet.
L: var.
Application
Template
According to
F: b C ISO7816-5, it includes 1
or more data objects
T: 61 If PSE present related to application
directory entry.
L: var. up to
252
File Control
Information
(FCI)
template It identifies the FCI

R template according to
F: var.
ISO7816-4.
T: 6F
L: var. up to
252
It is sent to the card after

Issuer Script C the final GENERATE
Template 2 Application Cryptogram
If issuer script
Command. It includes

Name (format;
tag; length)
F: b is supported. issuer proprietary data.
T: 72
L: var.
Directory
Discretionary
Template
It is the issuer
F: var. discretionary part in the
O
directory according to
T: 73 ISO/IEC 7816-5.
L: var. up to
252
Response
Message
Template
C Contains the data objects
Format 2
(with tags and lengths)
If CDA is returned by the card in
F: var.
supported. response to a command.
T: 77
L: var.
Response
Message
Template Contains the data objects
Format 1 (without tags and
R lengths) returned by the
F: var. card in response to a
T: 80 command.
L: var.
Application Byte 1:
Interchange bit 8: 1 = RFU;
It is a list specifying
Profile (AIP)
capabilities of the card to
bit 7: 1 = SDA is supported;
F: b 16 M support the designated
functions in the bit 6: 1 = DDA is supported;
T: 82 application.
bit 5: 1 = Cardholder
L: 2 verification is supported;

Name (format;
tag; length)
bit 4: 1 = Terminal risk

management is to be
performed;
bit 3: 1 = Issuer
Authentication is supported;
bit 2: RFU (0);
bit 1: 1 = CDA is supported;
Byte 2: RFU (“00”)
bit8: EMV Contactless

Specification reserved
bit 7 – bit 1： RFU(0)
Dedicated File
(DF) Name
F: b 40–128 It indicates name of DF

R
according to ISO7816-4.
T: 84
L: 5–16
It is delivered by the
issuer to the card
Issuer Script
through the terminal. It
Command
is included in issuer
F: b Script of the
O Please refer to Appendix B.
authorization response.
T: 86 Please refer to
descriptions on
L: var up to 261
command in Appendix
B.
bit 8:
Application C 1: Application shall not be
Priority
Indicates the priority of a selected without cardholder
Indicator
given application or confirmation;
F: b 8 If multiple
group of applications in 0: Application can be selected
payment
T: 87 a directory without cardholder
applications on
card confirmation;
L: 1
Bit 7-5: RFU (000)

Name (format;
tag; length)
Bit 4-1:
0000: Priority is not

specified.
xxxx: Order in which the

application is to be listed or
selected, ranging from 1 to
15, with 1 being the highest
priority
Short File Used in the commands

Identifier (SFI) related to an application 1–10: defined for UnionPay;
elementary file (AEF) to
F: b 8 11–20: payment system
R identify the file. The SFI
specific
T: 88 data object is a binary
field with three 21–30: Issuer specific.
L: 1 high-order bits set to 0
It is generated by the issuer in

line with ISO 8583 standard.
The following codes are

Authorization
generated by the terminal:
Response Code
It indicates the Y1: Offline approval
F: an 2 From the issuer
disposition of the
or the terminal Z1: Offline decline
T: 8A transaction
Y3: Cannot send online

L: 2
(Offline approval)
Z3: Cannot send online

(Offline decline)
Card Risk
Management
Data Object List List of data objects (tags
1 (CDOL1) and lengths) to be passed
to the card application
F: b M
with the first
T: 8C GENERATE AC
command
L: var. up to
252

Name (format;
tag; length)
Card Risk
Management
Data Object List List of data objects (tags
2 (CDOL2) and lengths) to be passed
to the card application
F: b M
with the second
T: 8D GENERATE AC
command
L: var. up to
252
Byte 1–4: Amount X (binary)
Byte 5–8: Amount Y (binary)
Byte 9 (CVM Code):
bit 8: 0 = Only values for

methods conforming to This
Specification ( discretionary
value if it is not 1);
bit 7:
1 = Applying succeeding
It lists all cardholder
Cardholder CVM field if the CVM fails;
verification methods
Verification supported by the card 0 =Fail Cardholder
Method (CVM) application in the verification if the CVM fails;
List priority sequence.
bits 6–1 (CVM Type):
F: b R Note: An application can
have several CVM Lists, 000000 = Fail CVM
T: 8E processing;
such as one for domestic
L: var. up to transactions and one for
000001 = The card performs
252 international
plaintext PIN verification;
transactions.
000010 = Enciphered PIN
verified Online;
000011 = The card performs

plaintext PIN verification and
signature (on paper);
000100 = RFU;
000101 = RFU;
011110 = Signature (on

paper);

Name (format;
tag; length)
011111 = CVM not required;
000110–011101 = RFU for

the joint payment systems;
100000–101111 = RFU for

individual payment systems;
110000–111110 = RFU for

the issuer;
111111 = RFU.
UnionPay defines:
100000 = Present cardholder

ID;
Byte 10 (CVM Condition

Code):
00 = Always;
01 = If ATM cash transaction;
02 = If not ATM cash

transaction or someone’s on
duty for the cash or cash back
transaction;
03 = If the terminal supports

the CVM;
04 = If there’s someone on
duty for the cash transaction;
05 = If cash back transaction;
06 = If the transaction
currency is same with the
application currency code and
the amount is less than X;
the amount is more than X;
the amount is less than Y;

Name (format;
tag; length)
the amount is more than Y;
0A–7F: RFU;
80–FF: RFU for each

payment system.
An additional 2 bytes is
added following byte 10 for
each additional CVM Code
and corresponding CVM
Condition
CA Public Key
Index (PKI)
C During offline SDA or
F: b 8 DDA process, it is used
If SDA or DDA together with RID to
T: 8F is supported. indicate CA public key.
L: 1
Issuer Public
Key Certificate C It is the issuer public key
certified by CA, which
F: b If SDA and can be used for offline
DDA are static and dynamic data
T: 90
supported. authentication.
L: NCA
It is the data used for

issuer authentication. It
Issuer is transmitted from the
Authentication terminal by the issuer to
Data the card.
F: b 64–128 O Under This

Specification, the issuer
T: 91 authentication data
consists of two parts:
L: 8–16
ARPC (8 bytes);
Authorization Response

Name (format;
tag; length)
Code (2 bytes).
Issuer Public
Key Remainder It is portion of the issuer
C public key modulus that
F: b does not fit into the
If required. Issuer Public Key
T: 92
Certificate.
L: NI-NCA+36
Signed Static
It is the digit signature
application Data
signed by the issuer,
(SAD) C generated from critical
F: b If SDA is card data elements and
supported. personalized on the card.
T: 93 It is validated by the
terminal during SDA.
L: NI
For each file to be read, AFL

includes four bytes:
Byte 1:
Bits 8–4 = SFI Short File

Identifier
Bits 3–1 = 000

Application File
Byte 2: Record number
Locator (AFL)
(cannot be 0) of the first
Indicates the location
F: var. record to be read for that SFI
(SFI, range of records)
R
T: 94 of the AEFs related to a Byte 3: Record number(=
given application or > Byte 2) of the last record
L: var. up to to be read for that SFI;
252
Byte 4: Number of
consecutive records involved
in authentication of static
data, starting with record
number in byte 2 (may range
from zero to the value of the
third byte minus the value of
the second byte +1)

Name (format;
tag; length)
Transaction
Certificate Data
Transaction Certificate Data
Object List C
Object List (TDOL)
(TDOL) List of the data objects
If cryptogram (tag and length) used by F: b
F: b version the terminal to generate
requires TC Hash Value. T: 97
T: 97
pre-hashing
L: var. up to 252
L: var. up to
252
Application
Discretionary
Data
Data specified by the
F: b 8–256 O issuer as related to the
card application.
T: 9F05
L: 1–32
Byte 1:
bit 8: 1 = Domestic cash

transaction is valid;
bit 7: 1 = International cash

transaction is valid;
bit 6: 1 = Domestic
commodity transaction is
Application It indicates restrictions valid;
Usage Control on card applications
bit 5: 1 = International
designated by the issuer,
F: b 16 commodity transaction is
O including regional
valid;
T: 9F07 application and service
type, etc. allowed for the bit 4: 1 = Domestic service
L: 2 card application transaction is valid;
bit 3: 1 = International
service transaction is valid;
bit 2: 1 = ATM transaction is

valid;
bit 1: 1 = Terminal
transaction (excluding ATM)
is valid.

Name (format;
tag; length)
Byte 2:
bit 8: 1 = Domestic cash back

is allowed;
bit 7: 1 = International cash

back is allowed;
bits 6–1: RFU (000000)
UnionPay restriction: in Byte

1, bit 4 equals to bit 6; bit 3
equals to bit 5.
Application
Version
Number. It is the version number
assigned by the payment
F: b 16 M
system for the
T: 9F08 application.
L: 2
Cardholder
If the cardholder name is Notes: Chinese characters
Name extended
more than 26 Bytes, the shall not be included in this
F: ans 27–45 complete part shall be tag; it may cause transaction
O
stored in this data rejections on small number of
T: 9F0B element. It is consistent terminals outside mainland
with ISO7813. China.
L: 27-45
It indicates the issuer’s

Issuer Action
conditions that causes
Code
R the transaction to be
(IAC)-default
declined when the card Bit assignments are identical
Will become requests an online to those for Terminal
F: b 40
mandatory in authorization, but the Verification Results (TVR).
T: 9F0D future terminal cannot
complete the online
L: 5
transaction
Issuer Action R
It indicates the issuer’s Bit assignments are identical
Code
Will become conditions that cause the to those for Terminal
(IAC)-Denial
mandatory in transaction to be Verification Results (TVR).
F: b 40 future declined without

Name (format;
tag; length)
T: 9F0E attempting to go online.
L: 5
Issuer Action
Code
R It indicates the issuer’s
(IAC)-online
Bit assignments are identical
Will become conditions that cause the
F: b 40 to those for Terminal
mandatory in transaction to be sent
Verification Results (TVR).
T: 9F0F future online.
L: 5
It is the proprietary
application data to be
sent to the issuer in an
online transaction.
The 1st byte is the length

of UnionPay
discretionary data.
Contents of the format:
Length (07) (1 byte);
Issuer Derivation Key Index (1

Application byte);
Data
Cryptogram Version
F: b R Number (1 byte);
T: 9F10 Card Verification Results

(CVR) (4 bytes);
L: var. up to 32
Algorithm ID (1 byte).
If the issuer
discretionary data is
present, the discretionary
data is followed by one
byte indicating the
length of issuer
discretionary data. The
next1-15 bytes consists
of the concatenated
issuer discretionary data

Name (format;
tag; length)
01 = ISO 8859, Part 1
02 = ISO 8859, Part 2
03 = ISO 8859, Part 3

Issuer Code
04 = ISO 8859, Part 4
Table Index C It indicates code table
for displaying the 05 = ISO 8859, Part 5
F: n 2 If application Application Preferred
Preferred Name Name according to 06 = ISO 8859, Part 6
T: 9F11
is present ISO8859.
07 = ISO 8859, Part 7
L: 1
08 = ISO 8859, Part 8
09 = ISO 8859, Part 9
10 = ISO 8859, Part 10
Preferred mnemonic
associated with the AID.
Application
Displayed by the
Preferred name
terminal during
F: ans 1–16 application selection if
O
any of the character sets
T: 9F12 designated in the Issuer
Code Table Index are
L: 1–16
supported by the
terminal
Last Online
Application
Transaction C
Counter (ATC)
If the card or
Register It is the ATC value of the
the terminal
velocity check last transaction went The initial value is 0.
F: b 16
or new card online.
T: 9F13 check to be
L: 2 performed
Lower limit of C It is the maximum times

consecutive of consecutive offline
If the terminal
offline transactions allowed for
velocity check
transaction the application in the
to be

Name (format;
tag; length)
F: b 8 performed terminal with online

processing capability as
T: 9F14
specified by the issuer.
L: 1
The initial value is the PIN

PIN Try try limit. For each
Counter authentication failure, the
C counter shall be decreased by
F: b 8 It specifies the number
If offline PIN is 1. When the correct PIN is
of remaining PIN try
T: 9F17 supported. entered or when the PIN is
changed or unblocked by the
L: 1 issuer, the counter shall be
reset to PIN Try Limit
Track 1
Discretionary
R
Data
It is the discretionary
Will be data in track i according
F: ans
changed to be to ISO/IEC 7813.
T: 9F1F optional.
L: var.
Upper limit of
Consecutive It is the maximum time
Offline C of consecutive offline
Transaction transactions allowed by
If the terminal the card before the card
F: b 8 velocity check requires online
is supported processing as specified
T: 9F23
by the issuer.
L: 1
Application
Cryptogram
(AC)
Generate the cryptogram
F: b 64 R for returning application
cryptogram.
T: 9F26
L:8

Name (format;
tag; length)
bits 8–7:
00 = AAC
01 = TC
10 = ARQC
11 = AAR (not supported by

Cryptogram this version)
Information It indicates the
bit 6–5: RFU (00)
Data cryptogram type
returned by the card and bit 4: 1 = Advice required;
F: b 8 R
specifies the actions to
bits 3–1 (Reason/advice/
T: 9F27 be performed by the
referral code):
terminal.
L: 1 000 = No information given;
001 = Service is not allowed;
010 = PIN try limit exceeded;
011 = Issuer authentication

failed;
xxx = RFU for all other.
Issuer Public
Issuer public key
Key Exponent C Exponent is used to
F: b If SDA and verify the Signed Static
DDA are Application Data and IC
T: 9F32 card public key
supported.
certificate.
L: 1 or 3
Application
Transaction
It records the times of
Counter
transaction processing
F: b 16 R after personalization. It
is maintained by the
T: 9F36 application in the card.
L: 2.
Processing C It is the list of terminal Processing Option Data

Option Data If terminal data related data objects (tags Object List (PDOL)
Object List needed for and lengths) requested

Name (format;
tag; length)
(PDOL) application by the card to be sent in F: b

initialization GET PROCESSING
F: b T: 9F38
OPTIONS Command
T: 9F38 L: var.
L: var.
Application C
currency code
If CVM
F: n3 requires Encoded in line with
amount check, ISO 4217.
T: 9F42
then this data is
L: 2 required.
Application
currency
exponent
It indicates the location
F: n 1 O of decimal from the right
side of amount data.
T: 9F44
L: 1
Data Value designated by the

Authentication issuer. During SDA, the
Code terminal recovers it from
the Signed Static
F: b 16 O
Application Data. It is
T: 9F45 stored in the card as part
of Signed Static
L: 2 Application Data.
IC Card Public
Key Certificate
C It is the IC card public
F: b key certified by the
If DDA is
T: 9F46 supported. issuer.
L: NI
IC Card Public C IC card public key

Key Exponent Exponent is used to
If DDA is verify the Signed

Name (format;
tag; length)
F: b supported. Dynamic Application

Data.
T: 9F47
L: 1 or 3
IC Card Public
Key Remainder
It is the IC card public
C key Modulus which do
F: b
If required. not fit within the IC card
T: 9F48 public key certificate.
L: NIC - NI + 42
Dynamic Data
Authentication
It is the list of data
Data Object List
objects (tags and
(DDOL) C lengths) to be delivered
F: b If DDA is by the terminal to the
supported. card in INTERNAL
T: 9F49 AUTHENTICATE
Command,
L: var. up to
252
Static Data
Contains list of tags of
Authentication
primitive data objects
Tag List
C whose value fields are to The list can only include tags
F: – be include in the Signed of Application Interchange
Static Application Data Profile (AIP).
T: 9F4A or IC card public key
certificate.
L: var.
Signed
Dynamic
Signed Dynamic
application Data C application Data is
F: b If DDA is generated by card. It is
supported. validated by the terminal
T: 9F4B during DDA.
L: NIC
IC Card C It is a random and

Dynamic time-variant number

Name (format;
tag; length)
Number If DDA is generated by the card

supported. during DDA processing.
F: b
It is transmitted to the
T: 9F4C terminal as included in
the signed dynamic data.
L: 2–8 Recovered by the
terminal
Log Entry
Byte 1:SFI of circulating
F: b 16 It provides number of transaction log files;
O SFI of log files and log
T: 9F4D file records. Byte 2: number of records in
transaction log files.
L: 2
Log Format
F: b It lists the tag and length

O of the data object in log
T: 9F4F file records.
L : var
Application
currency code C
UnionPay dedicated
F: n 3 If card velocity data. Encoded in line
check is to be with ISO 4217:2001
T: 9F51
performed
L: 2
UnionPay dedicated Byte 1:

data. It defines the
bit 8: 1 = if issuer
actions specified by the
authentication fails, send next
Application issuer and performed by
transaction online;
Default Action the card under certain
C
(ADA) conditions. bit 7: 1 = If Issuer
If Issuer authentication performed and
F: b 16 This data element is
Authentication failed, decline transaction;
required for Issuer
T: 9F52 supported
Authentication checks. bit 6: 1 = If issuer
L: 2 For other checks, if this authentication is mandatory
data element is not and no ARPC, decline
present, it will be taken transaction;
by default as zeros.
bit 5: 1 = If the transaction

Name (format;
tag; length)
declined offline, create

advice;
bit 4: 1 = If PIN Try Limit

Exceeded on current
transaction and the
transaction is declined,
Create advice;
bit 3: 1 = If the transaction

declined as issuer
authentication failed or not
performed, Create advice;
bit 2: 1 = If it is a new card,

send the transaction online;
bit 1: 1 = If it is a new card,

decline the transaction if it
cannot be sent online.
Byte 2:

exceeded on the current
transaction, block the
application;
Bit 7: 1 = If PIN Try Limit

exceeded on the previous
transaction, decline the
transaction;

transaction, send the
transaction online;

transaction when it cannot be
sent online;
bit 4: 1 = If issuer script

failed in the previous
transaction, send the
transaction online;


Name (format;
tag; length)

transaction and block the
application;
bits 2-1: RFU (000)
UnionPay dedicated data

Consecutive
element.
offline Consecutive offline
C
transaction limit The maximum number transaction limit
(international-c If velocity of consecutive offline (international-currency)
urrency) check is to be transactions without
F: b 8
performed on using application
F: b 8
international - designated currencies. If T: 9F53
T: 9F53 currency it is exceeded, the
L: 1
transaction will request
L: 1
online processing.
Accumulated UnionPay dedicated

offline C data.
transaction
If velocity It is the maximum limit
amount limit
check on on accumulated offline
F: n 12 accumulated transaction amount. If it
amount is to be is exceeded, the
T: 9F54
performed. transaction shall request
L: 6 for online processing.
Issuer
Authentication bit 8:
UnionPay dedicated
Indicator
C data. 1 = Issuer authentication is
F: b 8 mandatory;
If issuer It indicates when issuer
T: 9F56 authentication authentication is 0 = Issuer authentication is
is supported. supported, whether it is optional;
L: 1 mandatory or optional.
bits 7–1: RFU (0000000).
Issuer Country C UnionPay dedicated

Code data.
If card velocity
F: n 3 check is It indicates country of
supported. the issuer according to
T: 9F57 ISO 4217.
If regional

Name (format;
tag; length)
L: 2 check is
supported.
UnionPay dedicated
Lower limit of
data.
consecutive
C
offline It is the maximum times
transaction If the terminal of consecutive offline
velocity check transactions allowed for
F: b 8
to be the application in the
T: 9F58 performed terminal with online
processing capability as
L: 1
specified by the issuer.
UnionPay dedicated
Upper limit of
C data.
Consecutive
Offline If card velocity It is the maximum time
Transaction checking of consecutive offline
requires a transaction allowed for
F: b 8
decline if the card application
T: 9F59 online not before requiring online
available processing as specified
L: 1
by the issuer.
Issuer URL 2 It is defined by

UnionPay.
F: ans
O It indicates the location
T: 9F5A
of an issuer’s server on
L: var. the Internet.
UnionPay dedicated
Upper limit for data.
accumulated
C It is the maximum limit
offline
on offline transactions in
transaction If velocity the designated currency
amount check on or designated and
accumulated secondary currency
F: n 12
amount is to be allowed for the card
T: 9F5C performed. application before a
L: 6 transaction is declined
after an online
transaction is unable to

Name (format;
tag; length)
be performed
Cardholder ID
Number
O
F: an 40 Cardholder ID number.
T: 9F61
L: 1-40
00: ID card;
Cardholder ID 01: Military officer

Type certificate;
F: cn 1 It indicates the 02: Passport;

O
cardholder ID type.
T: 9F62 03: Entry Permit
L: 1 04: Interim ID card;
05: Others.
Bit 1- Bit 8: Bank

Identification Number[1]
Bit 9-11: product label
Bit 9:
Bit 8:1-Citizen card
Product Label Bit 7:1-Veteran card

Information Bit 6:1-Bonus card
Used to label the issuer
and card product type, Bit 5:1-Traffic card
0
F: b 128 and send to the issuer in Bit 4:1-Traffic card
the online transaction.
T: 9F63 Bit 3:1- Student card
L: 16 Bit 2:1- Air card
Bit 1:1- Public affair toll card
Bit 10: Reserved for Mobile

Payment Specification
Bit 8:1= Mobile payment
Bit 7-1: Reserved

Name (format;
tag; length)
Bit 11: Reserved for the

issuer
Bit 8-5, the value for the high

four as below:
0001=NFC-SD Mode
0010=NFC-SIM Mode
0011=NFC Full Mobile

Mode
0100=Dual Interface SD Card

Mode
0101=Dual Interface SIM

Card Mode
0110=Wire phone mode
0111=Pure Remote SIM Card

Mode
1000=Pure Remote SD Card

Mode
1001=Wireless phone mode
1010-1111 Reserved
Bit 4-1 Reserved, value

reserved for low four
Bit12－14: Reserved for the

specification
Bit 15－16：Reserved for the

issuer
Consecutive UnionPay dedicated data

offline C element.
transaction limit
If velocity The maximum number
(international-c
check is of consecutive offline
ountry)
performed on transactions beyond the
F: b 8 international - issuer’s country. If it is
country exceeded, the transaction
T: 9F72
shall request online

Name (format;
tag; length)
L: 1 processing.
Byte 1:
Currency bit 8-5: Location of the

Conversion C The decimal value used decimal separator from the
Factor to convert amounts in right;
If velocity second application
F: 8n check on dual currency to the bit 4-1: The first digit of the
currency is application designated currency conversion factor;
T: 9F73
performed. currency.
Byte 2-4: The remaining 6
L: 4
digits of the currency
conversion factor.
Accumulated
UnionPay dedicated
offline C
data.
transaction
If velocity
amount limit It is the maximum limit
check on
(dual on accumulated offline
accumulated
currencies) transaction amount (dual
amount (double
currencies). If it is
F: n 12 currencies) is
exceeded, the transaction
to be
T: 9F75 shall request for online
performed.
processing.
L: 6
Secondary
It is the secondary
Application C currency to be converted
Currency Code
If dual to the application
F: n 3 currency designated currency in
velocity check which the account is
T: 9F76 managed. It is encoded
is supported.
according to ISO 4217.
L: 2
File Control
Information
(FCI) . UnionPay Integrated
Circuit Card
template R Specifications - Basic
F: var. Specifications
proprietary data.
T: A5
L: var. up to

Name (format;
tag; length)
252
File Control
Information
(FCI) issuer
Discretionary
data
It is the issuer
O
F: var. discretionary part in FCI.
T: BF0C
L: var. up to
222
A.2 Card and Issuer Data Elements Requirements
Table A.2 specifies the requirements on the card and issuer data elements.
A.2.1 Tag
Column “Tag” specifies the tags of data elements.
A.2.2 Requirements Presence
Column “Mandatory/Conditional/Optional” specifies the requirements on data

elements. The items marked with * will be changed in the future. For detailed
descriptions, please refer to Column “Others”.
A.2.3 Data Integrity (Backup Required)
Column “Backup Required” specifies whether the data needs backup or not.
Under some special circumstances, such as sudden withdrawal of card and sudden
power down during transaction, the card shall be able to protect the application data
from damage.
A.2.4 Update Capability
Column “Update” specifies whether the data can be updated or not. If allowed, the
Update Commands are listed in Column “Command”.
A.2.5 Retrieval Capability
Column “Retrieval” specifies whether the data can be retrieved by the terminal or
returned to the terminal through commands. Data marked with “SD” can only be
retrieved from special devices. It cannot be retrieved by the terminal during
financial transaction.

A.2.6 Static or Dynamic
In card risk management data, “static” indicates that the data cannot be changed but
can be returned to the terminal through GET DATA command; “dynamic”
indicates that the data cannot be updated by the terminal through commands or
shall not be retrieved by the terminal.
A.2.7 Secret Data
Data marked as “Secret” shall be securely stored in the card. The data cannot be
retrieved by the terminal or other devices, nor updated for certain special
circumstances. PIN can be changed through Command PIN CHANGE /
UNBLOCK with secure messaging.
A.2.8 ADF Data
Column “ADF” specifies the data is stored under payment system ADF Directory.
The terminal reads the data during Application Selection through READ RECORD
Command.

Part 2: Debit/Credit Application Card Specification
A.2.9 Data Requirement List
Table A.2: Data Requirement List
Mand/
Backup Static /
Name Tag Cond/ Conditions Update Retrieve Secret data In ADF Others
required Dynamic
Opt
GENERATE
Application
9F26 R Application
Cryptogram (AC)
Cryptogram
Application Currency
9F42 C 29 N READ RECORD Match 9F51
Code
Application Currency GET DATA

9F51 C 1, 2 or 3 N Static Match 9F42
Code (special device)
Application Currency
9F44 C 1, 2, 3 or 29 N READ RECORD
Exponent
Application Default
9F52 C 19 Static
Action (ADA)
Application
9F05 O N READ RECORD
Discretionary Data

Mand/
Backup Static /
required Dynamic
Opt
Application Effective
Date
Application Expiration
5F24 M N READ RECORD
Date
GET
Application File
94 R N PROCESSING
Locator (AFL)
OPTIONS
Application Identifier
4F R N READ RECORD ADF
(AID)
Application GET
Interchange Profile 82 M N PROCESSING
(AIP) OPTIONS
READ RECORD *Mandatory

Application Tag 50 R* N ADF
SELECT in future

Mand/
Backup Static /
required Dynamic
Opt
Application Preferred READ RECORD

9F12 O N ADF
Name SELECT
Application PAN 5A M N READ RECORD
Application PAN
Sequence Number
Application Preferred READ RECORD

87 C 20 N ADF
Indicator SELECT
Application Transaction
9F36 R Backup N GET DATA 5, 6
Counter (ATC)
Application Usage
Control (AUC)
Application Version
9F08 M N READ RECORD
Number

Mand/
Backup Static /
required Dynamic
Opt
Card Risk
Management Data 8C M N READ RECORD
Card Risk Management

Data Object List 2 8D M N READ RECORD
(CDOL2)
GENERATE
Card Verification Part of
N Application
Results (CVR) 9F10.
Cryptogram
Will be C
Cardholder Name 5F20 R N READ RECORD
(9).
Cardholder Name
9F0B O N READ RECORD
Extension
Cardholder ID Number 9F61 O N READ RECORD
Cardholder ID Type 9F62 O N READ RECORD

Mand/
Backup Static /
required Dynamic
Opt
cardholder Verification
8E R N READ RECORD
Method (CVM) List
CA Public Key Index 8F C 30 or 31 N READ RECORD
Consecutive Offline Backup

Transaction Counter C 1 or default N N dynamic
(international-currency) as 9F53
Consecutive Offline
GET DATA
Transaction Limit 9F53 C 1 PUT DATA
(special device)
(international-currency)
Consecutive Offline Backup

Transaction Counter C 7 or default N N dynamic
(international-country) as 9F72
Consecutive Offline
GET DATA
Transaction Limit 9F72 C 7 PUT DATA
(special device)
(international-country)

Mand/
Backup Static /
required Dynamic
Opt
Cryptogram GENERATE
Information Data 9F27 R Application
(CID) Cryptogram
GENERATE
Cryptogram Version Part of
R N Application
Number 9F10.
Cryptogram
Backup
Accumulated Offline
C 2 or default N
Transaction Amount
as 9F54
Accumulated Offline
GET DATA
Transaction Amount 9F54 C 2 PUT DATA
(special device)
Limit
Upper Limit of
GET DATA
Accumulated Offline 9F5C O 2 or 3 PUT DATA
(special device)
Transaction Amount

Mand/
Backup Static /
required Dynamic
Opt
Accumulated Offline Backup

Transaction Amount C 3 or default N N dynamic
(dual currencies) as 9F75
Accumulated Offline
GET DATA
Transaction Amount 9F75 C 3 PUT DATA
(special device)
Limit (dual currencies)
Currency Conversion GET DATA

9F73 C 3 PUT DATA
Factor (special device)
Data Authentication
9F45 O READ RECORD Part of 93.
Code
Data Encryption DEA

C 10 N N Confidential
Key
Dedicated File (DF)

84 R N SELECT
Name

Mand/
Backup Static /
required Dynamic
Opt
Part of
Derivation Key Index O N N
9F10.
Directory Discretionary
73 O N READ RECORD
Template
Dynamic Data
Authentication Data 9F49 C 31 N READ RECORD ADF
Object List (DDOL)
Backup
DDA Failure Indicator C 31 or default N N dynamic
as 0
File Control
Information (FCI)
BF0C O N SELECT
Issuer Discretionary
Data
FCI Proprietary
A5 R N SELECT
Template

Mand/
Backup Static /
required Dynamic
Opt
FCI Template 6F R N SELECT
INTERNAL
ICC Dynamic Data C 31
AUTHENTICATE
INTERNAL Part of
ICC Dynamic Number 9F4C C 31
AUTHENTICATE 9F4B.
IC card public and

private key data
 Private key C 31 N N Secret
 Public key
Exponent 9F47 C 31 N READ RECORD
 Public key
certificate 9F46 C 31 N READ RECORD
 Public key
remainder 9F48 C 15 N READ RECORD
Issuer Action Code * Will be

9F0D R* N READ RECORD
-default mandatory.

Mand/
Backup Static /
required Dynamic
Opt
Issuer Action Code Will be

9F0E R* N READ RECORD
-denial mandatory.
Issuer Action Code Will be

9F0F R* N READ RECORD
-online mandatory.
GENERATE
Issuer Application Data 9F10 R N Application
Cryptogram
Issuer Authentication
91 O 19
Data
Backup
Issuer Authentication
C 19 or default N N dynamic
Failure Indicator
as 0 or 1
Issuer Authentication GET DATA

9F56 C 19 N static
Indicator (special device)

Mand/
Backup Static /
required Dynamic
Opt
Issuer Code Table

9F11 C 16 N SELECT
Index
must match
Issuer Country Code 5F28 C 17 N READ RECORD
9F57.
GET DATA must match

Issuer Country Code 9F57 C 7,12 N static
(special device) 5F28.
Issuer Public Key Data

90
 Issuer public C 30 or 31 N READ RECORD
key certificate
 Issuer public
key Exponent 9F32
C 30 or 31 N READ RECORD
 Issuer public key
remainder
92 C 15 N READ RECORD

Mand/
Backup Static /
required Dynamic
Opt
Backup
Issuer Script Command
Counter
as 0
Backup
Issuer Script Failure
Indicator
as 0 or 1
Issuer Script Template

72 C 18
2
Issuer URL 9F50 O SELECT
Issuer URL 2 9F5A O SELECT
Preferred Language 5F2D O SELECT
Backup
ATC register for the GET DATA 5, 6 or
9F13 C 4,5,6,8 or 24 or default N
last online transaction 24
is 1

Mand/
Backup Static /
required Dynamic
Opt
SELECT
Log Entry 9F4D O ADF
Application
Log Format 9F4F O GET DATA
Lower limit of
UPDATE
consecutive offline 9F14 C 5,6,24 Backup READ RECORD
RECORD
transaction
Lower limit of
GET DATA
consecutive offline 9F58 C 4 Backup PUT DATA
(special device)
transaction
Message Authentication
C 18 and 28 N N Secret
Code (MAC) DEA key
Default
Online Authorization
R as 1 or N N dynamic
Indicator
Backup

Mand/
Backup Static /
required Dynamic
Opt
Backup PIN
PIN Try Counter 9F17 C 21 or default CHANGE / GET DATA 27
as limit UNBLOCK
PIN Try Limit C 21 N N Secret
Processing Option Data

9F38 C 22,12 SELECT
Object List (PDOL)
PIN
Offline PIN C 21 Backup CHANGE / N Secret
UNBLOCK
Response Message
80 R N N
Template Format 1
Second Application GET DATA

9F76 C 3 N static
Currency Code (special device)
Service Code 5F30 O N READ RECORD

Mand/
Backup Static /
required Dynamic
Opt
SELECT
Short File Identifier GET
88 N
(SFI) PROCESSING
OPTIONS
Signed Dynamic INTERNAL

9F4B C 31 n/a
Application Data AUTHENTICATE
Signed Static
93 C 30 N READ RECORD
Application Data
Backup
SDA Failure Indicator C 30 or default N N dynamic
as 0
Static Data (30 or 31)

9F4A C N READ RECORD
Authentication Tag List and 32
Track 1 Discretionary UPDATE Will be

9F1F R READ RECORD
Data RECORD25 optional.

Mand/
Backup Static /
required Dynamic
Opt
Must be
Track 2 Equivalent UPDATE
57 M READ RECORD Record 1
Data RECORD25
that SFI=1.
Transaction Certificate
Data Object List 97 C 23 N READ RECORD
(TDOL)
Unique DEA key R N N Secret
Upper Limit of
UPDATE
Consecutive Offline 9F23 C 5,6,24 Backup READ RECORD
RECORD
Transaction
Upper Limit of
GET DATA
Consecutive Offline 9F59 C 8 Backup PUT DATA
(special device)
Transaction
Product Label
Information

A.2.10 Data Requirement list - Condition Number List
For the detailed conditions corresponding to the condition No. in the Data
requirement list, please refer to the table below.
Table A.3: Condition Number List
Condition
Descriptions
No./Code
Data can only be retrieved from the designated device. This procedure is not
Special device
performed for financial transaction.
If the card performs velocity check on consecutive offline transaction

1
(international – currency).
2 If the card performs velocity check on accumulated amount.
3 If the card performs velocity check on accumulated amount (dual currencies).
If the card performs velocity check on lower limit of consecutive offline

4
transaction.
If the terminal performs velocity check on lower limit of consecutive offline

5
transaction.
If the terminal performs velocity check on upper limit of consecutive offline

6
transaction.
If the card performs velocity check on consecutive offline transaction

7
(international – country).
If the card performs velocity check on upper limit of consecutive offline

8
transaction.
9 If present in Magnetic stripe.
10 If changes of offline PIN value or other confidential data are supported.
11 If directory method of application selection is supported

Condition
Descriptions
No./Code
12 If region restriction check is supported during application initialization.
If corresponding public key certificate is present and entire public key does
15
not fit into certificate
16 If application preferred name is present.
17 If Application Usage Control (AUC) is present
18 If issuer script is supported.
19 If issuer authentication is supported.
20 If the card has several payment applications.
21 If offline PIN is supported.
22 If terminal data is required during application initialization.
23 If cryptogram version requires pre-hashing.
24 If new card check to be performed.
25 If update of the PVV is supported.
26 If cardholder verification is supported.
27 If “Last PIN attempt” is to display
28 If secure messaging technique is supported.
29 If any CVM List conditions use amounts.
30 If SDA is supported.

Condition
Descriptions
No./Code
31 If DDA is supported.
32 If primitive data objects are to be signed.
34 If transaction details is required to be recorded.
A.3 Regulations on the Definition of Card and Issuer Data Element
A BER-TLV data object can contain two or three successive fields:
 Tag (T): Define the type of Data Object, its length can be 1 or 2 byte
 Length (L): Define the length of subsequent field, the data object length used in
the interaction between card and terminal can be 1 or 2 byte.
Remarks: In the Issuer script, the length may be 3 bytes, but in this specification we
will only discuss the data object in card-terminal interaction.
 Value (V): Define the value of the data object. If Length (L) = "00", V does not
exist.
BER-TLV data object can be classified as two types:
 Basic data object: V includes only one data element.
 The structure data object: Value includes one or many basic data objects or
constructed data object, and the value of the latter is called template.
Table A.4 Definition of the first byte of BER-TLV 1
B8 B7 B6 B5 B4 B3 B2 B1 Definition
0 0 Universal class
0 1 Application class
1 0 Context-specific class
1 1 Private class

0 Primitive data object
1 Constructed data object
1 1 1 1 1 subsequent byte
Value lower than 31 Tag Number
Table A.5 BER-TLV Tag subsequent number definition
B8 B7 B6 B5 B4 B3 B2 B1 Definition
1 There is subsequent byte
This byte is the last byte of this

0
tag
Any value larger than zero A part of the tag number
Padding byte "00" can appear in the template. The padding byte must appear before,
after or in-between the basic data objects, and cannot appear in the basic data
objects, and the length (L) of the Constructed data object must include the length of
the padding byte. (For example, length variation due to the deletion or amendment
of basic data object. In such circumstances, the padding byte "00" may appear in the
value of Constructed data object which include that basic data.)
If the application class data object is defined in ISO/IEC 7816, and then we should
follow the definition and application method in ISO/IEC 7816.
'61 to 6F' , as "application class templates”, are defined as '61 to 6F' in ISO/IEC
7816.
'70 to 7F', as application class template, are defined in various parts in this
specification. '78', '79', '7D' and '7E' are defined in ISO/IEC 7816-6, but are not
adopted in the specification.
Context-specific class data object should follow the definitions in this specification.
'80' to '9E' and '9F01' to '9F4F' are reserved by EMV.

'9F50' to '9F7F' are reserved for this specification.
‘BF20’ and ‘BF4F’and ‘BF0C’are reserved by EMV.
'BF10' to 'BF1F' and 'BF50' to 'BF6F' are reserved by this specification.
'BF01-BF0B', 'BF0D' to 'BF0F' and 'BF70' to 'BF7F' are reserved by Issuer.
'DF01' to 'DF7F' are reserved by this specification.

Appendix B Command Specification
This Appendix describes the commands applied in different chapters and supported
by the card.
 APPLICATION BLOCK (Issuer Script Command)
 APPLICATION UNBLOCK (Issuer Script Command)
 CARD BLOCK (Issuer Script Command)
 EXTERNAL AUTHENTICATE
 GENERATE APPLICATION CRYPTGRAM (AC)
 GET DATA
 GET PROCESSING OPTIONS
 INTERNAL AUTHENTICATE
 PIN CHANGE / UNBLOCK (Issuer Script Command)
 PUT DATA (Issuer Script Command)
 READ RECORD
 SELECT
 UPDATE RECORD (Issuer Script Command)
 VERIFY
The commands above can be used for other purpose, such as card personalization.
The terminal sends commands to the card, and the card returns command responses
to the terminal after processing is completed. For each command, CLA and INS
bytes indicate the command type; parameter byte P1 and P2 provides additional
processing information. A command can also include a data field.
Command Response includes two status bytes (SW1 and SW2) that describes
command results. When a command is complete successfully, SW1 and SW2 equal
to “9000”. Other values indicate that the command is not complete correctly.
Response to a command may also include response data.
B.1 Basic Processing Rules for Issuer Script Command
Issuer Script Command of some special functions shall be sent to the card from the
device under the issuer’s control during non-financial transactions, such as
APPLICATION UNBLOCK AND PIN CHANGE/UNBLOCK.
Issuer script command requires secure messaging. Message Authentication Code

(MAC) is used to verify whether the command comes from a valid issuer or not and
guarantee that the command is not changed during transmission. If the command

includes confidential data such as cardholder PIN, the data shall be encrypted for
protection.
B.2 APPLICATION BLOCK Command C-APDU/R-APDU
B.2.1 Definition and Applicable Scope
APPLICATION BLOCK command is an Issuer script command which is used to

disable the selected application.
After APPLICATION BLOCK command is performed successfully:
 For SELECT command, invalid application shall returned FCI and status byte
“The file selected is invalid” (SW1 SW2='6283').
 For GENERATE AC command, an invalid application shall return AAC rather

than AC for response.
B.2.2 Command Message
APPLICATION BLOCK command message is encoded according to the table

below:
Table B.1: APPLICATION BLOCK Command Message
Code Value
CLA ‘84’
INS ‘1E’
P1 ‘00’; other values are reserved for future use.
P2 ‘00’; other values are reserved for future use.
Lc Byte length of data field.
Data field 4 bytes of MAC value.
Le Not present
B.2.3 Data Field of Command Message
Data field of command message includes MAC data encoded in accordance with
the Secure Messaging format specified in the Security Specification.

B.2.4 Data Field of the Response Message
Response message has no data field.
B.2.5 Processing Status of Response Message
No matter whether the application is valid or not, '9000' code always indicates that
the command is successfully performed.
B.3 APPLICATION UNBLOCK Command C-APDU/R-APDU
APPLICATION UNBLOCK command is an Issuer Script Command used to

restore the current application selected.
When APPLICATION UNBLOCK command is performed successfully, the block

restriction on the application completed through APPLICATION BLOCK can be
released.
APPLICATION UNBLOCK command message is encoded according to the table

below.
Table B.2: APPLICATION UNBLOCK Command Message
Code Value
CLA ‘84’
INS ‘18’
P1 ‘00’; other values reserved.
P2 ‘00’; other values reserved.
Data field MAC value of 4 bytes.
Le Not present
the Secure Messaging format specified in the Security Specification.

B.3.5 Processing Status Returned by the Response Message
No matter whether the application is valid or not, '9000' code indicates that the
command is performed successfully.
B.4 CARD BLOCK Command C-APDU/R-APDU
CARD BLOCK command is a post-issuance command which is used to terminate

all applications in the IC card permanently.
CARD BLOCK command stops all applications in the IC card, including those
hidden applications.
When a CARD BLOCK command is successfully performed, all succeeding

SELECT commands will receive the feedback of the status byte “The function is
not supported” (SW1 SW2='6A81') and no other action will be executed.
CARD BLOCK command message is encoded according to the table below.
Table B.3: CARD BLOCK Command Message
Code Value
CLA ‘84’
INS ‘16’
P1 ‘00’; other values reserved for future use.
P2 ‘00’; other values reserved for future use.
Data field MAC value of 4 bytes.
Le Not present

the Secure Messaging format described in the Security Specification.
No matter whether the card has been blocked or not, '9000' code indicates that the
command is performed successfully.
B.5 EXTERNAL AUTHENTICATE Command C-APDU/R-APDU
EXTERNAL AUTHENTICATE command requires application in the IC card to

authenticate a key.
IC card response shall include processing status of the command.
For each transaction, EXTERNAL AUTHENTICATE command can be performed

at most once.
EXTERNAL AUTHENTICATE command message is encoded according to the

table below.
Table B.4: EXTERNAL AUTHENTICATE Command Message
Code Value
CLA ‘00’
INS ‘82’
P1 ‘00’
P2 ‘00’
Lc 8-16
Data field Issuer authentication data

Code Value
Le Not present.
Algorithm (P1) value cited in EXTERNAL AUTHENTICATE command is ‘00’,

which indicates that the field has no information. It further indicates that citing of
algorithm has been completed before using the command, or it is defined in the
data field of this command.
According to the UnionPay rules, the data field of this command message includes
the range whose tag is '91'. It is encoded as follows:
 The first 8 bytes are mandatory Authorization Response Cryptogram ARPC.
 The additional 1 to 8 optional bytes are dedicated data.
In this version, issuer authentication data consists of the following two data
elements:
 ARPC (8 bytes);
 Authorization response code (2 bytes).
“9000” code indicates that the command is performed successfully.
If verification fails, “6300” is returned. If during the transaction, the card has
received the EXTERNAL AUTHENTICATE command, the card will return
“6985”.
B.6 GENERATE Application Cryptogram Command C-APDU/R-APDU
GENERATE AC command transmits relevant transaction data to IC card, and then

IC card calculates and returns a cryptogram. This cryptogram is an application
cryptogram (AC) defined in the specification. The table below lists the types of
cryptogram.
Table B.5: Types of GENERATE Application Cryptogram

Type Meaning
Application Authentication Cryptogram

Transaction decline
(AAC)
Authorization Request Cryptogram (ARQC) Online authorization request
Transaction Certificate (TC) Transaction approval
Cryptogram returned by IC card may differ from cryptogram required in the

command message due to the internal processing of the IC card.
GENERATE AC command message is encoded according to the table below.
Table B.6: GENERATE AC Command Message
Code Value
CLA ‘80’
INS ‘AE’
P1 Cited control parameters (refer to Table B.7).
P2 ‘00’
Lc Var.
Data field Transaction related data.
Le ‘00’
Cited control parameters in GENERATE AC Command are encoded according to

the table below.
Table B.7: GENERATE AC Cited Control Parameters

b8 b7 B6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC
1 1 RFU.
Combined Dynamic Data

Authentication
0 /Application Cryptogram
Generation is not
requested specifically.
Combined Dynamic Data

Authentication
1
/Application Cryptogram
Generation is requested.
x x x x x RFU.
Data field of command message is the terminal data used to generate Application
Cryptogram. The detailed data contents are specified in Appendix D.
Algorithm about generating the cryptogram is described in Appendix D.
Data field of the response message includes a data object encoded in BER-TLV.
The data object needs to be encoded in either of the following two formats.
Format 1:
The data object in the response message is an elementary data object whose tag is
'80'. Data field in connected by the data objects specified in the table below. There
is no separator (tag and length) between data objects.
Table B.8: Format 1 for Data Field of GENERATE AC Response Message

Value Requirement
Cryptogram Information Data Mandatory
Application Transaction Counter (ATC) Mandatory
Application Cryptogram (AC) Mandatory
Issuer application data Optional
Format 2:
The data object of response message is a structure data object whose tag is '77'.
Data field can include several BER-TLV encoding objects, but it must include
Cryptogram Information Data, Application Transaction Counter and the
cryptogram calculated by the IC card (an application cryptogram or dedicated
cryptogram). Response messages that may include application and interpretation to
dedicated data objects are not within the scope of This Specification.
If the response message is the signature data defined in Chapter 9, 14 and 16 under
Part VII of This Specification, Format 2 shall be adopted to answer CDA. For
format of the response data unit, please refer to 5.3.6 of the Security Specification.
If the card does not execute CDA, data objects in data field of the Command
Response message shall be encoded according to Format 1. If the card executes
CDA, data objects in data field of the Command Response message shall be
encoded according to Format 2.
For the two formats above, cryptogram data included in Response message of
GENERATE application cryptograms command is encoded according to the
methods specified in the table below:
Table B.9: Encoding of Cryptogram Information Data (CID)
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
0 0 AAC
0 1 TC
1 0 ARQC

1 1 AAR
x x Payment system cryptogram
0 Advice is requested.
1 Advice is requested.
Reason/Advice/authorization reference
x x x
code
0 0 0 No information.
0 0 1 Service is not allowed.
0 1 0 PIN try exceeds the limit.
0 1 1 Issuer authentication failed.
Other values are reserved for future

x x x
use.
B.6.5 Processing Status Returned by the Response Message.
'9000' code indicates the command is performed successfully.
For one transaction, the card can process at most two GENERATE Application
Cryptogram Command. If three or more such commands are received, the card will
return “6985”.
B.7 GET DATA Command C-APDU/R-APDU
B.7.1 Definition and applicable scope
The part below describes the data accessed on a special device through GET DATA
Command during non-financial transaction, and the access of data with GET
DATA command during the financial transaction.
 Special device

 The table below specifies the static data which can be accessed by special
devices under the issuer’s control through GET DATA Command and
cannot be obtained by ordinary terminals through GET DATA Command.
Table B.10: Static Data Accessed with GET DATA Command
Data Element
Application currency code (9F51)
Application Default Action (9F52)
Consecutive offline transaction limit (international-country) (9F72)
Consecutive offline transaction limit (international-currency) (9F53)
Accumulated offline transaction amount limit (9F54)
Accumulated offline transaction amount limit (dual currencies) (9F75)
Upper limit of accumulated offline transaction amount (9F5C)
Currency conversion factor (9F73)
Issuer authentication indicator bit (9F56)
Issuer country code (9F57)
Lower limit of consecutive offline transaction (9F58)
Upper limit of consecutive offline transaction (9F59)
Second application currency code (9F6B)
Limit of card CVM (9F6B)
 Financial Transaction
GET DATA Command is used to obtain an elementary data object that is not
packaged in the records from the current application. GET DATA Command can
be used to basic data objects ATC (tag '9F36'), ATC register for the last online

transaction (tag '9F13') or cryptogram try counter (tag '9F17') and log format (tag
'9F4F').
GET DATA Command message is encoded according to the table below.
Table B.11: GET DATA Command Message
Code Value
CLA ‘80’
INS ‘CA’
P1 P2 Tag of the data to be accessed.
Lc Not present
Data field Not present
Le ‘00’
Command message has no data field.
Data field of the response message includes elementary data objects (including tag
and length) described in P1 P2 of command message.
If the data requested in the command cannot be returned as it is dedicated data, the
card returns “6A88”.
B.8 GET PROCESSING OPTIONS Command C-APDU/R-APDU
GET PROCESSING OPTIONS Command is used to start transactions in the IC

card.
Response message of the IC card includes Application Interchange Profile (AIP)

and Application File Locator (AFL).

GET PROCESSING OPTIONS Command message is encoded according to the

table below.
Table B.12: GET PROCESSING OPTIONS Command Message
Code Value
CLA ‘80’
INS ‘A8’
P1 P2 ‘00’
Lc ‘00’
Data field PDOL related data (if any) or 8300
Le ‘00’
Data field of command message shall be encoded in line with the Processing Data
Object List (PDOL) provided by the IC card. PDOL is marked with tag “83”. When
IC Card does not provide the Data Object List, data length field of the template will
be set as 0. Otherwise, data length field of the template will be equal to the total
length of the data object range transmitted to the IC card.
Data field of the response message includes a data object encoded according to
BER-TLV.
This data object needs to be encoded in line with one of the following two formats:
Format 1:
Data object of the response message is an elementary data object whose Tag is '80'.
The data field consists of the connected ranges of Application Interchange Profile
(AIP) and Application File Locator (AFL) specified in the table below. There is no
separator between data objects (tag and length).
Table B.13: Format for Data Field of GET PROCESSING OPTIONS Response
Message

‘80’ Length Application Interchange Profile AFL
Format 2:
Data object of the response message is an elementary data object whose Tag is '77'.
The data field may consists of multiple objects encoded by BER-TLV but shall
contains Application Interchange Profile (AIP) and Application File Locator
(AFL).
Application Interchange Profile defines the functions supported by the application

in the IC card.
AFL includes a list of files and records without any separator.
B.8.5 B.8.5 Processing status Returned by the Response Message
B.9 INTERNAL AUTHENTICATE Command C-APDU/R-APDU
INTERNAL AUTHENTICATE Command makes the card to use random number

received by IFD, data and private key stored in the card to calculate the “signed
dynamic application data’.
INTERNAL AUTHENTICATE Command is encoded according to the table

below.
Table B.14: INTERNAL AUTHENTICATE Command Message
Code Value
CLA ‘00’
INS ‘88
P1 ‘00’
P2 ‘00’
Lc Length of authentication related data

Code Value
Data field Authentication related data
Le ‘00’
Value of cited (P1) field for algorithm of INTERNAL AUTHENTICATE

Command is ‘00’, which indicates that this value has no meaning. It further
indicates that citing of algorithm shall be or has been completed before the
command, or it is defined in the data field of this command.
Data field of command message includes authentication related data dedicated to

the application. It is encoded in line with Dynamic Data Authentication Data
Object List (DDOL) rules defined in Part VII of This Specification.
In order to restrict INTERNAL AUTHENTICATE Command response data within

256 bytes, the length of Signed dynamic Application data and optional TLV format
codes shall be controlled within the scope defined in UnionPay Integrated Circuit
Card Specifications - Basic Specifications Part4:Debit/Credit Application Security
Specification of This Specification.
Data field of the response message includes a data object encoded according to
BER-TLV. The data object shall be encoded in the following format:
Data object of the response message is an elementary data object whose Tag is ‘80’.
The data field includes signed dynamic application data, which shall be defined in
line with rules specified in the UnionPay Integrated Circuit Card Specifications -
Basic Specifications Part4:Debit/Credit Application Security Specification n.
B.10 PIN CHANGE / UNBLOCK Command C-APDU/R-APDU
PIN CHANGE/UNBLOCK Command is an issuer script command. Its aim is to

make the issuer unblock PIN or change PIN and unblock PIN.
When PIN CHANGE/UNBLOCK Command is executed successfully, the card will

perform the following functions:
 To reset the value of PIN try counter to the PIN try limit (maximum value);

 Set a new PIN for offline PIN value if requested.
For confidentiality, if the command includes any PIN data, the data shall be
encrypted.
Note: Offline PIN refers to the PIN related to the application and stored in the card.
It is used to verify PIN data transmitted from the command.
PIN CHANGE/UNBLOCK Command message is encoded according to the table

below.
Table B.15: PIN CHANGE/UNBLOCK Command Message
Code Value
CLA ‘84’
INS ‘24’
P1 ‘00’
P2 ‘00’、‘01’ or ‘02’
Lc Bytes of data
Data Data elements of encrypted PIN (if any) and MAC data
Le Not existing.
When P2 is “00”, PIN try counter shall be reset.
When P2 is “01”, PIN try counter shall be reset and PIN shall be changed. Current
PIN shall be used during PIN change.
When P2 is “02”, PIN try counter shall be reset and PIN shall be changed. Current
PIN shall not be used during PIN change.
Data field of command message includes PIN encrypted data which can be
followed by 4 to 8 bytes of Secure Messaging MAC data.

If P2 is ‘00’, refer to PIN UNBLOCK and PIN try counter is reset to PIN try limit.
Command Data field only includes MAC. As PIN CHANGE / UNBLOCK
Command does not include new PIN value, PIN will not be updated.
When P2 equals to ‘01’ or ‘02’, the processing procedures are specified in B.10.1
and B.10.2.
B.10.3.1 PIN Change Based on Current PIN Value
If parameter P2 in the command equals to “01”, Command Data field includes PIN
encrypted data and MAC. PIN encrypted data shall be generated through the
following steps:
1. The issuer uses the Secure Messaging for data encryption to encrypt Master
Key and separately generate the card Secure Messaging Encrypted Unique
DEA Keys: ENC UDK-A and ENC UDK-B.
2. To generate session keys Ks;
3. To generate PIN data block D3 of 8 bytes:
a) To generate an 8-byte data block D1:
Byte 1 Byte 2 Byte 3 Byte 4 Byte 5 Byte 6 Byte 7 Byte 8
0 0 0 0 0 0 0 0 4 bytes at the flush right of ENC UDK-A.
b) To generate another 8-byte data block D2:
0 N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
N: quantity of numbers in the new PIN (Hex);
P: value of the new PIN, length is 4-12 numbers (2-6 bytes).
c) D1 and D2 execute XOR to obtain D3.
4. To use the current PIN to generate an 8-byte data block D4:
P P P P P/0 P/0 P/0 P/0 P/0 P/0 P/0 P/0 0 0 0 0
5. D3 and D4 execute XOR to obtain D;

6. To encrypt 8 byte data block D with Ks and obtain PIN encrypted data.
B.10.3.2 PIN Change Based on No Current PIN Value
If parameter P2 of the command equals to “02”, the command Data field includes
PIN encrypted data and MAC. PIN encrypted data is generated through the
following procedures:
1. The issuer determines the Secure Messaging encryption Master Key for data
encryption, and scattered generates the card Secure Messaging Encryption
Unique DEA Keys: ENC UDK-A and ENC UDK-B.
2. To generate session key Ks;
3. To generate PIN data block D3 of 8 bytes:
a) To generate an 8-byte data block D1:
0 0 0 0 0 0 0 0 4 bytes at the flush right of ENC UDK-A.
b) To generate another 8-byte data block D2:
0 N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
N: quantity of numbers in the new PIN (Hex);
P: value of the new PIN, length is 4-12 numbers (2-6 bytes).
c) D1 and D2 execute XOR to obtain D.
4. To encrypt D with session key Ks and obtain PIN encrypted data.
‘9000’ code indicates the command is performed successfully.

B.11 PUT DATA Command C-APDU/R-APDU
PUT DATA Command is used to change the value of some elementary data objects
in the card. Only the data with tags can be changed with this Command. This
command cannot be used to change structural data object.
B.11.1.1 Data That Can be Changed with PUT DATA Command
The table below specifies the data that can be changed with this Command.
Table B.16: Data Changed with PUT DATA Command
Data Element
Consecutive offline transaction limit (international-country) (9F72)
Consecutive offline transaction limit (international-currency) (9F53)
Accumulated offline transaction amount limit (9F54)
Accumulated offline transaction amount limit (double currencies) (9F75)
Upper limit of accumulated offline transaction amount (9F5C)
Currency conversion factor (9F73)
Lower limit of consecutive offline transaction (9F58)
Upper limit of consecutive offline transaction (9F59)
Limit of card CVM (9F6B)
PUT DATA Command message is encoded according to the table below.
Table B.17: PUT DATA Command Message
Code Value
CLA ‘04’

Code Value
INS ‘DA’
P1 P2 Tag of the data objects to be changed
Lc Bytes of data field
Data field New value of data objects (excluding tag and length) and MAC data
Le Not existing.
Command Data field includes data objects to be changed. The MAC with 4 to 8
bytes is added. For calculation of MAC, please refer to Appendix C.
The table below describes the possible warning information returned by this
command:
Table B.18: Warning Response Code to PUT DATA Command
SW1 SW2 Meaning
62 00 No response information.
62 81 The data is possibly damaged.
The table below specifies possible error information returned by this Command.
Table B.19: Error Response Code to PUT DATA Command
SW1 SW2 Meaning
64 00 No exact diagnosis.

SW1 SW2 Meaning
65 81 Memory failure.
67 00 Mistaken length.
68 82 Secure Messaging is not supported.
69 82 Security status is not satisfied.
69 86 The command is not permitted.
69 87 Secure Messaging data object is lost.
69 88 Secure Messaging data object is not correct.
6A 80 Wrong parameter.
6A 81 The function is not supported.
6A 84 The file has no enough space.
6A 85 Lc is not consistent with TLV in terms of structure.
B.12 READ RECORD Command C-APDU/R-APDU
READ RECORD command reads a file record from a linear file.
Response from the IC card will include the record read out.
READ RECORD Command message is encoded according to the table below.
Table B.20: READ RECORD Command Message
Code Value
CLA ‘00’

Code Value
INS ‘B2’
P1 record number
P2 Cited control parameters, Refer to Table B-20
Lc Not existing.
Data field Not existing.
Le ‘00’
The table below defines the cited control parameters of the command message.
Table B.21: Cited Control Parameters of READ RECORD Command
b8 B7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x SFI
Read the record designated by

1 0 0
P1
Command message has no data field.
For any successful READ RECORD command, data field of the response message
shall include the records read out. For SFI ranging from 1 to 10, the record is a
structural data object encoded with BER-TLV. Encoding shall be carried out in line
with the table below.
Table B.22: Data Field of READ RECORD Response Message
‘70’ Length Record template
For SFI ranging beyond 1-10, This Specification is not applicable for response
message of READ RECORD Command.

B.13 SELECT Command C-APDU/R-APDU
SELECT command selects PSE, DDF or ADF in IC card through file name or AID.
Application selection is specified in Chapter 4 of this book.
After the command is successfully executed, path of PSE, or ADF is set.

Succeeding commands work on AEF which is corresponding to PSE, or ADF
selected with SFI.
Response message from the IC card includes response FCI.
For the codes of SELECT command message, please refer to the table below:
Table B.24: SELECT Command Message
Code Value
CLA ‘00’
INS ‘A4’
P1 Cited control parameters (Refer to Table B-24)
P2 Select Options (Refer to Table B-25)
Lc ‘05’ - ‘10’
Data File name.
Le ‘00’
The table below defines the cited control parameters of SELECT command
message:
Table B.25: Cited Control Parameters of SELECT Command
B8 b7 b6 b5 b4 b3 b2 b1 Meaning

0 0 0 0 0
1 Selected by name.
0 0
The table below defines SELECT Option P2 in SELECT command message:
Table B.25: Optional Parameters of SELECT Command
0 0 The first one or only one.
1 0 Next one.
B.13.3 Data field of command message
Data field of the command message shall include the name of PSE and DF selected
or AID.
B.13.4 Data Field of Response Message
Data field of the response message shall include FCI of PSE, or ADF selected.
Table B.26, Table B.27 and Table B.28 define the tags of applications specified in
This Specification. Additional tags responded in FCIs that are beyond scope of This
Specification shall be omitted. Card cannot use any padding byte in FCI, however,
it should be successfully received and correctly transmitted instead of rejection
when the terminal receives FCI with padding bytes.
The table below defines FCI responded after PSE is successfully selected:
Table B.26: Response Message (FCI) Selecting PSE
Tag Value Existence
‘6F’ FCI template M
‘84’ Name of DF (1PAY.SYS.DDF01) M
‘A5’ FCI data dedicated template M
‘88’ SFI of Directory Elementary File M
‘5F2D’ Language selection O

‘9F11’ Issuer code table index O
‘BF0C’ Issuer custom data (FCI) O
One or more additional

‘XXXX’ (dedicated) data elements
(Tag specified in coming from application O
Volume 3) provider, the issuer or the
IC card supplier.
The table below defines FCI responded after ADF is successfully selected:
Table B.27: Response Message (FCI) Selecting ADF
Tag Value Existence
‘6F’ FCI template M
‘84’ Name of DF M
‘A5’ FCI data dedicated template M
‘50’ Application tag O
‘87’ Application priority indicator O
‘9F38’ PDOL O
‘5F2D’ Preferred language O
‘9F11’ Issuer code table index O
‘9F12’ Application priority name O
‘BF0C’ Issuer custom data (FCI) O
One or more
‘XXXX’ additional (dedicated)
data elements coming
(Identifier specified in O
from application
Volume 3) provider, the issuer or
the IC card supplier.
‘9F4D’ Log entry O

Note: for the card with several applications, it is strongly recommended that
“Application tag” data element shall be included in the response message so that
when the terminal uses “AID list” method to select application, the cardholder can
easily select/confirm the application.
B.13.5 Status Code of Response Message
Status code for successful perform of the command is ‘9000’.
It is not mandatory whether IC card shall support DF file selection by partial DF

name. However, if IC card does support file selection by partial name, it must
comply with the following rules:
After a DF is successfully selected, when the terminal repeatedly sends SELECT

Commands and P2 is set at the option to select the next file with the same partial
DF name, the card shall select a different DF file that matches the partial DF name
(if any). If there is no application level command interference, when the same
SELECT Commands are sent repeatedly, the card shall be able to find all DF files
that satisfy the conditions and each file shall not be located twice. When all DF
files that satisfy the conditions are selected, if the same SELECT Command is sent
out again, there shall be the result of no file selection any more. The card shall
respond SW1SW2=‘6A82’ (the file is not found).
B.14 UPDATE RECORD Command C-APDU/R-APDU
UPDATE RECORD Command is used to change contents of a record in the file.

Change contents are stored in data field of the Command.
B.14.2 Command message
For the code of UPDATE RECORD Command message, please refer to the table
below:
Table B.28: UPDATE RECORD Command Message
Code Value
CLA ‘04’
INS ‘DC’
P1 record number
P2 Cited control parameters, Refer to Table B-29

Code Value
Lc Length of record data and MAC.
Data Record data and MAC.
Le Not existing.
The table below defines the cited control parameters of the command message.
Table B.29: Cited Control Parameters of UPDATE RECORD Command
b8 B7 b6 b5 b4 b3 b2 b1 Meaning
x x x x x SFI
1 0 0 P1 is record number
Data field specifies the new record contents to be changed. MAC length is 4 to 8
bytes. For algorithm, please refer to Appendix C.
B.14.4 Data field of the Response Message
The table below specifies possible warning information that may be returned by the
Command:
Table B.30: Warning Response Code to UPDATE RECORD Command
SW1 SW2 Meaning
62 00 No information returned.
62 81 The data may be damaged.
The table below specifies possible error information that may be returned by the
Command.

Table B.31: Error Response Code to UPDATE RECORD Command
SW1 SW2 Meaning
64 00 No exact diagnosis.
65 81 Memory failure.
67 00 Mistaken length.
68 82 Secure Messaging is not supported.
Command is not consistent with the file in terms of

69 81
structure.
69 82 Security status is not satisfied.
69 86 Command is not allowed.
69 87 Secure Messaging data object is lost.
69 88 Secure Messaging data object is not correct.
6A 81 The function is not supported.
6A 82 The file is not found.
6A 83 The record is not found.
6A 84 There is no sufficient space in the file.
6A 85 Lc is not consistent with TLV in terms of structure.
B.15 VERIFY Command C-APDU/R-APDU
VERIFY Command makes IC card to compare Transaction PIN data in data field
of the Command message with relevant reference PIN data of the application for
verification. Verification mode is decided by the application in IC card. As it is

specified in Chapter 11 of this book, if the cardholder verification method (CVM)

selected from the CVM List is offline PIN, VERIFY Command shall be applied.
VERIFY Command message is encoded according to the table below.
Table B.32: VERIFY Command Message
Code Value
CLA ‘00’
INS ‘20
P1 ‘00’
P2 Definition of reference data.
Lc var.
Data Transaction PIN data.
Le Not existing.
The table below defines meanings of reference data (P2).
Table B.33: Meanings of Reference Data to VERIFY command (P2)
0 0 0 0 0 0 0 0 Definitions in IOS/IEC 7816-42
1 0 0 0 0 0 0 0 Plaintext PIN in the following formats
1 0 0 0 0 x x x Reserved in this Specification.
1 0 0 0 1 0 0 0 Reserved for EMV.
2
P2=’00’ is not adopted in this specification.

1 0 0 0 1 0 x x Reserved for This Specification.
1 0 0 0 1 1 x x Reserved for the Payment System.
1 0 0 1 x x x x Reserved for the Issuer.
For VERIFY command processing procedures and CVM rules, please refer to
Chapter 11 of this book.
Data blocks of plaintext offline PIN, please refer to the following format
organization.
C N P P P P P/F P/F P/F P/F P/F P/F P/F P/F F F
In which:
Name Value
C Control field 4 bit binary number (hex. 2) valued at 0010
4 bit binary number (hex. ‘4’ to ‘C’) valued between 0010

N PIN length
and 1100
4 bit binary number (hex. ‘0’ to ‘9’) valued between 0000

P PIN number
and 1001
PIN/supplementar
P/F Depend on PIN length.
y bit
F Supplementary bit 4 bit binary number (hex. ‘F’) valued at 1111.
If P2 equals to ‘00’, it indicates that there is no special qualifier. The application in

IC card that deals with Command authentication shall clearly know how to find
PIN data correctly.
Data field of command message includes a range whose Tag is ‘99’.

B.15.5 Processing Status in the Response Message
If for the application currently selected, it is detected through VERIFY Command

that the comparison between Transaction PIN Data and reference PIN data fails, IC
card will return SW2=‘Cx’ of which ‘x’ indicates the times of further verifications;
if IC card returns ‘C0’, then there shall not be any more verification and CVM will
be blocked. After that, all VERIFY Commands in this Application will fail and the
Card will return SW1 SW2=‘6983’.

Appendix C Secure Messaging
This Appendix describes how secure messaging is used in Issuer Script Command.
The basic purpose of secure messaging is to ensure the confidentiality of data and
message integrity and to perform issuer authentication. Message integrity and
issuer authentication are realized through MAC, while data confidentiality is
realized through encipherment of plaintext Command data.
C.1 Format of Secure Messaging
Secure Messaging described in this Specifies is consistent with ISO7816-4 standard.

If the second nibble of CLA byte in the Command is equal to hexadecimal 4, the
Command will adopt Secure Messaging format.
C.2 Message Integrity and Authentication (MACing)
Message authentication code (MAC) is generated based on all data elements in the
Command including Command head. Command Integrity including data field part
(if any) shall be guaranteed through Secure Messaging.
C.2.1 MAC Location
MAC is the last data element in the Command data field.
C.2.2 MAC Length
According to UnionPay, length of MAC shall be 4 bytes.
C.2.3 MAC Key Generation
During Secure Messaging processing, session keys of MAC key are used. For
generation of session key, please refer to C.4. MAC session keys are generated by
the Secure Messaging authentication (MAC) key (MAC UDK) in the card.
C.2.4 MAC Calculation
MAC calculation is started after encipherment of any confidential data in the

command. The MAC is generated using triple DEA encipherment specified as
follows:
1. An initial vector is set equal to 8 bytes of hexadecimal zeros (this step can be
ignored);
2. The following data is concatenated in the order specified to create a block of

data:
 CLA, INS, P1, P2, Lc (Lc indicated the length of the data included in the
command);
 Last ATC (for issuer script processing, this is the ATC transmitted in the
request message);

 Last Application Cryptogram (for issuer script processing, this is usually

the ARQC transmitted in the request message; when the application
cryptogram has been blocked prior to transmission of the request, the
Application Cryptogram is an AAC);
 Plaintext or enciphered data in Command Data field (if present).
3. This block of data is formatted into 8-byte data blocks, labeled D1, D2, D3,D4,
and so forth. The last data block may be 1 to 8 bytes in length;
4. If the last data block is 8 bytes, an additional 8 bytes data block is concatenated
to the right of the last data block as follows: Hexadecimal 80 00 00 00 00 00
00 00. Proceed to step 5.
If the last data block is less than 8 bytes, it is padded to the right with a-byte
hexadecimal 80. If the length reaches 8 bytes, step 5 shall be performed. If the
length is still less than 8 bytes, it is right filled with 1 byte hexadecimal until the
length is 8 bytes.
5. Use MAC session keys to encipher the data blocks. For generation of MAC
session keys, please refer to C.4 Session Key Generation.
Figure below is the flow chart illustrating how MAC is generated from MAC
session key A and B.
6. Calculation result of MAC is 8 bytes, obtain 4 bytes from the left.
Initial
初始值 value I2 I3 I4 I5
KM
DEA(d)
B
+ KMA DEA(e) KMA DEA(e) KMA DEA(e) KMA DEA(e)
O5
I1=D1 O1 O2 O3 O4
KM
DEA(e)
A
+ + +
O6
D2 D3 D4
MAC
Note:
说明：
I = 输入 D = 数据块
UPI Confidential
DEA(e)= 数据加密算法（加密模式） KMA = MAC过程密钥A 232
DEA(d)= 数据加密算法（解密模式） KMB = MAC过程密钥B
O = 输出 + = 异或
I = Input D = Data block
DEA(e) = Data Encryption Algorithm KMA = MAC session key A

(Encryption Mode)
DEA(d) = Data Encryption Algorithm KMB = MAC session

(Decryption Mode) key B
0 = Output + = x or
Figure C.1: Algorithm for MAC Calculation with Double Length DEA Key
C.3 Data Confidentiality
Data encipherment is used to guarantee the confidentiality of the plaintext data

required for the Command.
C.3.1 Data Encipherment Key Calculation
During Secure Messaging processing, Data Encipherment session key is used for
generation of session key, please refer to C.4 GENERATE Session Key. Data
Encipherment session key generation process is seeded with the card’s Data
Encipherment DEA Key (ENC UDK).
C.3.2 Structure of Enciphered Data
When the plaintext data in commands needs to be enciphered, it is first formatted

into the following block of data:
 Length of the plaintext data excluding pad characters (Ld);
 Data plaintext;
 Pad characters (refer to C.3.3 Data Encipherment Calculation).
And then the entire block of data is enciphered using the data encipherment
technique..
C.3.3 Data Encipherment Calculation
Data encipherment is performed before MAC generation in the following

procedures:
1. Set Ld as length of the plaintext data；
2. The block of data created in step 1 is divided into 8 bytes data blocks, labeled
D1, D2, D3, D4. and so forth. The last data block shall be 1 to 8 bytes in
length;

3. If the last (or only) data block is equal to 8 bytes, proceed to step 4. if the last
data block is less than 8 bytes, it is padded to the right with a-byte hexadecimal
80. If the length reaches 8 bytes, step 4 shall be performed. If the length is still
less than 8 bytes, it is right filled with 1 byte hexadecimal until the length is 8
bytes
4. Each data block is enciphered with data encipherment session keys. For
generation of session keys, please refer to C.4 GENERATE Session Key.
The table below illustrates the encipherment process on data blocks with data
encipherment session key A and B.
DN
KDA KDB
DEA(e) DEA(d)
O1 O2
KDA
DEA(e)
加密的DN
说明： Enciphered Dn
Note:DEA(e)= 数据加密算法（加密模式） D = 数据块

DEA(d)= 数据加密算法（解密模式） KMA = MAC过程密钥A
O = 输出 KMB = MAC过程密钥B
DEA(e) = Data Encryption Algorithm D = Data block
(Encipherment Mode)
DEA(d) = Data Encryption Algorithm KDA = MAC session

(decipherment Mode) key A
0 = Output KDB = MAC session

key B
Figure C.2: Data Encipherment with Double Length DEA Key
5. After the previous steps are completed, all enciphered data blocks are
concatenated together in order (enciphered D1, D2, D3. and so forth…). The
resulting block of data is inserted in the command data field

C.3.4 Data Decipherment Calculation
After receiving the Command, the card will decipher the enciphered data in the
Command Data field through the following procedures:
1. Divide the block of data in the Command data field into 8 bytes blocks, labeled:
D1, D2, D3, D4, and so forth. Each data block is deciphered using the data
encipherment session key.
The figure below illustrates how the data encipherment session key A and B
decipher the data blocks.
DN
KDA KDB
DEA(d) DEA(e)
O1 O2
KDA
DEA(d)
解密的DN
说明： Deciphered Dn
Note: DEA(e)= 数据加密算法（加密模式） D = 数据块

DEA(d)= 数据加密算法（解密模式） KMA = MAC过程密钥A
O = 输出 KMB = MAC过程密钥B
DEA(e) = Data Encryption Algorithm D = Data block
(Decipherment Mode)
DEA(d) = Data Encryption Algorithm KDA = MAC session key A

(Decipherment Mode)
0 = Output KDB = MAC session key B
Figure C.3: Data Decipherment with Double Length DEA Key
2. After Decipherment is completed, all the deciphered data blocks are

concatenated together in order (Deciphered D1, D2, D3, and so forth). The
resulting block of data is composed of the recovered LD, the recovered
plaintext data, and the recovered pad characters

3. Since Ld indicates the real length of the plaintext data.
C.4 Session Key Generation
This section describes the procedures of session key generation:
1. Card keys used to generate session keys are MAC DEA Key A and B (MAC
UDK), data encipherment DEA Key A and B (ENC UDK) for the selected
cryptographic process
2. Make 2-byte ATC right aligned and padded with 6 bytes of 00 on the left (refer
to Invert 2-byte ATC and make it right aligned and padded 6 bytes of 00 on the
left(refer to the UnionPay Integrated Circuit Card Specifications - Basic
Specifications Part4:Debit/Credit Application Security Specification for
details).

Appendix D Authentication Key and Algorithm
This Appendix describes keys and algorithms related to the generation of the online
authentication cryptogram ( AAC, TC and ARQC).
D.1 Data Source
The issuer shall decide the data source that generates application key.
The table below specifies the data order of GENERATE application cryptogram.
Table D.1: Data Element Order of TC/AAC/ARQC
Data from Order if in TC

Data Element Input by card
terminal Hash value
Authorized amount √ √
Other amounts √ √
Terminal country code √ √
Terminal Verification √ √
Results
Transaction currency √ √
code
Transaction date √ √
Transaction type √ √
Unpredictable Number √ √
Application Interchange √
Profile (AIP)
Application transaction √
counter (ATC)
Card Verification Results √

(CVR)

D.2 Generating the TC\AAC\ARQC
The TC, AAC and ARQC are generated by putting selected data into the algorithm.
This process includes following steps:
1. The first GENERATE AC command, the terminal shall transmit to the card the
data specified in CDOL1. In the second GENERATE AC command, the
terminal shall transmit to the card the data specified in CDOL2.
If the TC Hash value is referenced in CDOL1, the terminal shall transmit

the TC Hash Value in the first and second GENERATE AC command.
2. Based on internal card risk management results, the card determines whether to
return a TC/AAC or an ARQC in the response message.
The card shall concatenate the following data in the order specified to create a
block of data:
 Transaction Certificate (TC) Hash Value (if present);
 Data objects transmitted from the terminal in the GENERATE AC

command for input to the cryptogram in the order specified by the
cryptogram version selected. The TC hash Value is not included.;
 Data elements input directly by the card into the cryptogram in the order
specified by the cryptogram version selected.
3. The card shall format this block of data into 8 bytes data block, labeled each:
D1, D2, D3, D4. and so forth
4. If the last data block is 8 bytes, 8 bytes shall be padded: 80 00 00 00 00 00 00

00; if the last group is less than 8 bytes, one byte 80 shall be padded. If the
length is still less than 8 bytes, 00 shall be padded to the data block until the
length is 8 bytes.
5. Use the session key to generate application cryptogram through DEA key
algorithm;
6. Session key is generated with the unique DEA key (UDK) in the card. For the
detailed generation procedures, please refer to C.4. The figure below illustrates
how session Keys A and B are used to generate application cryptogram.

I1=D1 I2 I3 I4 I5
KB DEA(d)
KA DEA(e) KA DEA(e) KA DEA(e) KA DEA(e) KA DEA(e)
06
O1 O2 O3 O4 O5
KA DEA(e)
+ + + +
O7
D2 D3 D4 D5
TC/AAC/ARQC
说明：
I = 输入
Note: D = 数据块
DEA(e)= 数据加密算法（加密模式） KA = 密钥A
DEA(d)= 数据加密算法（解密模式） KB = 密钥B
O = 输出
I = Input+ = 异或
D = Data block
DEA(e) = Data Encryption Algorithm KA = Key A

(Encipherment Mode)
DEA(d) = Data Encryption Algorithm KB = Key B

(Encipherment Mode)
0 = Output + = x or
Figure D.1: TC/AAC/ARQC Generation Algorithm
D.3 Generating the Authorization Response Cryptogram (ARPC)
When the card receives the EXTERNAL AUTHENTICATE Command, it

generates a reference ARPC for comparison to the APRC delivered in the
Command. Procedures for Generating ARPC are as follows:
1. The card shall perform an exclusive-OR processing with Application

Cryptogram and Authorization Response Code;
Application Cryptogram used in the exclusive-OR processing shall be the

cryptogram transmitted in the request message, which is usually the ARQC. Under
certain processing condition, the Application Cryptogram may be an AAC.

The ARQC transmitted in the request message is used as input to the exclusive-OR
algorithm. There is no need for the card to recalculate the ARQC.
The Authorization response code used in the exclusive-OR processing shall be the
one transmitted to the card in the Issuer Authentication data in the EXTERNAL
Authenticate command. Prior to Exclusive-OR processing, the code left justifies
the Authorization Response Code in an 8-byte field and zero fills (hexadecimal 0)
the remaining 6 bytes.
2. The results of the exclusive-OR processing shall be as the data input to an 8

byte data block D1;
3. Session keys shall be used to generate ARPC with DEA key algorithm. The
figure below illustrates the ARPC generation method.
I1=D1
KA DEA(e)
O1
KB DEA(d)
O2
KB DEA(e)
O3
Note:
说明：
I = 输入 I = Input D = 数据块 D = Data block

DEA(e)= 数据加密算法（加密模式） KA = 密钥A
DEA(d)= 数据加密算法（解密模式） KB = 密钥B
O = 输出
DEA(e) = Data Encryption Algorithm KA = Key A
(Encipherment Mode)

DEA(d) = Data Encryption Algorithm KB = Key B

(Encipherment Mode)
0 = Output
Figure D.2: ARPC Generation Algorithm
D.4 Derivation Key Methodology
This part describes the methodology of key derivation. The unique DEA key in the
card is generated through Master DEA Key (MDK) derivation during card
personalization.
The figure below illustrates the generation process of unique DEA Keys A and B.
Issuer host
security module
The issuer generates the
double length Master DEA
key (MDK). MDK
During personalization, the PAN and PAN

issuer generates unique sequence No.
DEA key A and unique
DEA key B (UDKA and DEA
UDKB) for each IC card. (Encryption
Decryption MDK
UDKA use application Encryption)
primary account number
and PAN sequence number
to perform 3DES
calculation generation. UDKA
Inverted PAN and

UDKB use inverted
application primary PAN sequence No.
account number and PAN
serial number to execute DEA
3DES calculation (Encryption
generation. Decryption
Encryption)
UDKB
Figure D.3: Key Derivation
To derive the Unique DEA Key A, the Application PAN and Application PAN
sequence number shall be concatenated together in a 16-hexadecimal field. (If the
Application PAN Sequence Number is not present, it shall be zero filled). If the

length of the application PAN followed by the Application PAN sequence number
is less than 16 numbers, the following formatting rules shall be applied:
 If the length is less than 16 numbers, right-justify the data in a 16-hexadecimal

and pad on the left with hexadecimal zeros;
 If the length is more than 16 numbers, use only the right-most 16 digits
To derive the Unique DEA Key B, the Application PAN and Application PAN
Sequence Number shall first be concatenated together in a 16-hexadecimal field
using the formatting rules as above, and then inverted. Inversion shall be performed
at the bit level, where each bit with value ‘1” is set to “0” and each bit with value
“0” is set to “1”.
The figure below illustrates the card authentication process with unique DEA Key
A and B (UDKA and UDKB).
1. The terminal IC card Data

sends data related
to the transaction
to the card.
Data
DEA UDKs
2. IC card uses ARQC
UDK encrypted
data to generate Terminal
ARQC to return to PAN and PAN
the terminal. sequence No.
3. The terminal 3 Data, Authorization

delivers ARQC ARQC response
and relevant data DEA MDKs
to the issuer for Issuer Data
authentication.
4. The issuer uses UDKs Terminal

MDK to re-scatter
UDKs and
authenticates
ARQC ARQC
Figure D.4: Card Authentication with UDK
As indicated in the figure, the derivation of the Unique DEA Keys shall be
performed in a host security module and the verification of the ARQC shall also be
performed in a host security module.

Appendix E Supported Cryptogram Version
The Cryptogram version defined by UnionPay is 01 (0x01).
The table below specifies the data elements of GENERATE TC/AAC and ARQC
and the order.
Table E.1: Data of Generate TC/AAC and ARQC
Data element Data from terminal Data in card
Authorized amount 
Other amounts 
Terminal country code 
Terminal Verification Results 
Transaction currency code 
Transaction date 
Transaction type 
Unpredictable number 
Application Interchange Profile


(AIP)
Application transaction counter


(ATC)
Card Verification Results (CVR) 
Cryptogram Version 01 uses the symmetric key algorithm specified in the Security
Specification to generate Application Cryptogram.

Appendix F Algorithm Identification
Algorithm Identification is the data defined by UnionPay in the issuer discretionary

data element. The data defines the algorithm used by the card to generate the
Application Cryptogram and Secure Messaging. The length is one byte and the
value shall be:
Table F.1: Algorithm Identification
Algorithm Value (Hex)
3DES 01
SSF33 02

Appendix G (Explanatory Appendix)Account Management under

Low-value payment function
The issuer can set an upper limit of authorized transactions for each card while issuing an
electronic cash application. That limit is depended on each card and managed internally by the
Issuer. That account is called “electronic cash account”.
In the issuer host system of the Issuer, the Electronic Cash Account can be managed as an
independent account. The cardholder can transfer the amount to the electronic cash account in
the following ways1)：
——Transferring from the primary account;
——Cash Loading;
——Transferring through the third party.
The following conditions may affect the differences between the electronic cash account
amount and Electronic Cash Balance:
——Delay between the time of transaction execution, the time of Issuer’s acceptance and
transaction record clearing;
——Delay between the time of Issuer’s loading of electronic cash account and the time of
updating of Electronic Cash Balance of the financial IC card (through the Issuer script
command, requiring that the card and the Issuer should be connected online);;
——Exception Processing.
1）
What the Issuer needs to know is that, the Electronic Cash Account Balance is a provision for offline
transaction which has not been submitted for clearing. Any offline-authorized transaction should be cleared
against the Electronic Cash Account Balance. Therefore, the Electronic Cash Account Balance does not
always reflect the Electronic Cash Balance of the card.

Graph 1 shows the different constituent parts of the function patterns for Low-value
Payment.
Card loading
Transfer of amount
Cardholder primary
Card2 EC Account4
Unload account3
n
tio
sac
ran
in et
Purchase ffl
o
ear
Cl Authorize and
Clear Online
Transaction
Terminal1
Figure 26: Function Patterns of Low-value Payment
Note 1: “Terminal” refers to any financial chip terminal which is compatible with
debit/credit application of This Specifications may have an online capability or not.
Note 2: “Card” refers to the financial IC cards which conform to the debit/credit
application program of This Specifications are personalized and capable of executing
Low-value Payment Transaction.
Note 3: “Cardholder primary account” is supposed to be the current account used in the
Note 4: "Electronic Cash Account" has reserved to the electronic cash amount in advance,
for:
——Preventing the electronic cash amount from being used for non-Low-value payment;
——Clearing the offline transaction for the card.
G.1 Offline Transaction
In the offline transaction, the card uses the risk management internally to determine
whether the transaction may be authorized offline. The card will compare the current authorized
amount with Electronic Cash Balance. If the current authorized amount exceeds the Electronic
Cash Balance of the card, it must request the online authorization.
If the transaction is approved offline, the card will deduct the authorized amount of this
transaction from the Electronic Cash Balance. If the card requests the online authorization but
the terminal does not support online function, it will perform the standard debit/credit
transaction processing.

The offline transaction does not have any impact on the Issuer system. For the offline
transaction, the Issuer may modify its host system so that more checks can be executed in the
clearing processing. For instance, the system shall check the Application Transaction Counter
(ATC) received to determine whether there are any outstanding transactions to be submitted for
clearing.
G.2 Online Transaction
Reasons that require the transaction to be processed online:
——The difference between Electronic Cash Balance and the authorized amount is lower than
the Electronic Cash Reset Threshold;
——Exceptions occur during the transaction which forces the transaction to be conducted
online (e.g. The cardholder is unable to enter the correct offline PIN).
In general, the host system will execute the same processing as other financial IC card
authorizations on the electronic cash account during online processing, includes:
——check if the card is reported for lost or stolen;
——perform online CAM by verifying the ARQC which is sent in field 55;
——check the data content on the chip to find out the causes why the transaction is sent to
online.
If an additional processing is required depends on the reasons that the transaction is sent for
online processing, such as insufficient Electronic Cash Balance or enter incorrect PIN. The
issuer host system will execute different authorization processing according to those reasons.
If the authorized amount is higher than the card’s Electronic Cash Balance, the transaction will
be sent for online processing. This is the most common condition that a transaction is sent for
online processing. The corresponding authorization processing mode will be determined by the
Issuer itself, host system will execute any additional test and check defined by the Issuer in its
authorization processing.
——The transaction is only authorized to the cardholder’s primary account. The balance of
primary account should be checked. If the balance is sufficient, the transaction will be
approved while the host system will return the authorization approval to the card and the
money is disbursed from the primary account; but the Electronic Cash Balance still remain
unchanged (please see “Example 1: For authorization to primary account transaction, the
authorized amount is RMB 20 Yuan”);
——Issuer loads to cardholder’s Electronic Cash account automatically. Issuer will activate
“auto-load” process each time during an online processing or when the Electronic Cash
Balance is lower than the Electronic Cash reset threshold..(please see “Example 2: During
online authorization, issuer loads to Electronic Cash account automatically until the
Electronic Cash balance is RMB 50 );
The processing results of the host system as above are shown in the following figures:

Example 1: Authorization to Primary Account transaction, the Authorized Amount is

RMB 20
Before Transaction
Primary Account Balance=50
EC Balance=10
Figure 27: Primary Account Transaction Authorization Example (1)
Transaction Onlin
Amount of RMB e auth
oriza
tion r
20 Yuan eques
t
The Host system checks The
primary account balance, and
authorized and sends ARPC
tion val
riza o
u tho appr
A se =
The Card authenticates the po n
res
issuer, and confirms
authorization approval,
but not updates the offline
counter.
After Transaction
EC Balance=10
Example 2: the Issuer automatically loads the Electronic Cash Balance to RMB 50 during
the online authorization
Before Transaction

Primary Account
Balance=80
EC Balance=10 EC Account Balance=10
Figure 30: Automatic Loading Example (1)
The transaction of RMB 20

Yuan exceeds the card balance.
Card Offline risk management
determines to go for online
processing, and the card Auth onli
oriza ne
generates ARQC tion r
eques
t
The host system has an automatic

Loading protocol to check if the primary
account balance is higher than the
Loading amount + Current transaction
amount. In this case, the primary account
balance (80) > loading amount (40) +
Current transaction amount (20)
The host Transfers

RMB 40 Yuan to the
EC Account.
Figure 31: Automatic loading Example (2)
40
EC Account Balance=50
EC Balance=10

The host Authorizes the current

transaction to the primary account.
And it sents the script, indicating to
"set the EC Balance As the balance
value agreed in advance (RMB 50
Yuan in this example)”
n
rizatio
Autho Approval
se =
respon
The card completes the

transaction. EC Balance is set
to the agreed value.
After Transaction
EC Balance=50 EC Account Balance=50
Primary Account
Balance=20
Figure 34: Automatic Loading Example (5)

Appendix H (Informative Appendix) Electronic -Cash Balance and Log

Reader
This Appendix contains functional requirements for the balance of the financial IC card
including the electronic cash and the card log reader.
H.1 Overview
H.1.1 Overview of Requirements
There are 2 types of requirements for Electronic Cash:
—— Business requirements;
—— Security requirements.
Electronic Cash balance can meet these requirements in the following methods:
—— Improving the function for cardholder’s options;
—— Increasing the flexibility for members to manage the risk in offline transactions.
The cardholder may use a portable and low-cost personal device to check the Electronic Cash
Balance, or the transaction log on the card. In this way, the personal device may facilitate the
electronic cash solution to meet those demands.12)
H.1.2 Overview of Requirements
Personal device (card reader) must meet the following business requirements:
—— Support to display Electronic Cash balance;
—— Support to display transaction log entry;
—— The Card reader should be cheap, with self-contained power supply and normal life cycle
over five years;
—— The Card reader may provide some other characteristics except for this specification.
The below types of personal device must support the functions listed in Table H.1.
Table H.1 Functions to be supported by Personal Devices
Functions
Device types Balance display Transaction log display
12）
This personal device is not only for Electronic Cash, but for other applications since it is in accordance
with CUP’s IC card enterprise standards.

Card Balance reader M N/A
Card Log reader M M
(Note: M—Mandatory, N/A—Not applicable)
H.1.3 Security Requirements
Security requirement for personal device (card reader) is:
—— Balance, currency and transaction log must accurately reflect the data in card.
—— If the device allows software upgrades, there should be some mechanism to ensure
the primitively and integrity of the device, and upgrades must be reviewed and
approved prior to installation;
—— Card reader must not retain or display any card-related information after the card has
been removed.
H.2 Overview of Functionality
H.2.1 Electronic Cash Balance
Electronic Cash balance is usually used GET DATA command to read balance from card.
H.2.2 Obtaining Electronic Cash Balance Using GET DATA Command
Electronic Cash balance is received through the following processings:
1. Power card on;
2. Select application;
3. Use GET DATA command to read Electronic Cash balance
In addition, card reader must be able to read currency code from the card and convert it into text
format.
H.2.3 Displaying Transaction Log
Please refer to Table H.2 for the procedure of displaying transaction log.

Table H.2 Procedure for Displaying Transaction Log
Step Action
1 Card reader checks if transaction logs exist
2 Card reader reads a series of tags representing log format and currency type from card
3 Card reader uses a sequence of READ RECORD commands to read logs from card
4 Card reader displays data to cardholder
All items should be displayed by scrolling; specific format and method should be defined by
Issuers and will not be elaborated here.
H.3 Functional Requirements
H.3.1 Electronic Cash Balance
H.3.1.1 Obtaining Electronic Cash Balance
Table H.3 shows the tags that must be defined in card reader in order to complete the
processings for getting Electronic Cash balance.
Table H.3 Pre-defined Terminal Tags for Acquiring EC Balance
Tag Type Description
9F79 B EC balance
9F51 N Application Currency Code
To execute "read Electronic Cash balance" processing, card reader will perform the following
steps:
1. Card reader selects card application. If the return code of card application is not
"successful", the card reader will terminate "get Electronic Cash balance" process and
generate "card not accepted" as a return code;
2. Card reader uses GET DATA command to get Electronic Cash balance. Please refer to
Table H.4 for the definition of GET DATA command.
Table H.4 Reading EC Balance by Using GET DATA Command

Code Value
CLA 80
INS CA
P1 9F
P2 79
LE 00
3. If the return status bit of GET DATA command is not "9000", the card reader will
terminate "get Electronic Cash balance" process and generate "card not accepted" as a
return code;
4. Card reader checks the returned Electronic Cash balance through the verification tag
"9F79". If the card does not return an Electronic Cash balance, the card reader will
terminate "get Electronic Cash balance" process and generate "card not accepted" as a
return code.
H.3.1.2 Displaying Electronic Cash Balance
There is no recommended method for displaying data and it is strictly depends on the capability
of display feature. The following recommendations are for guidance only:
—— The balance should be shown in the format of 3-letter currency code and balance, and be
formatted according to decimal points;
—— If currency (currency symbol) and balance cannot be displayed at the same time due to
limitation of display size, the reader should display the balance first and follows by
currency (currency symbol) shortly afterward, and then it should be switched each other
in display.
If the display string does not support the characters required by currency code, currency code
should be used 3 spaces instead.
H.3.2 Transaction Log
H.3.2.1 Reading Transaction Log
Card reader reads transaction logs from card during "read transaction log" process.
Table H.5 shows the tags that must be defined by terminal to complete reading transaction log
process.
Table H.5 Pre-defined Terminal Tags for Reading Transaction Logs

Tag Type Description
84 B DF name
9F4F B Log format
9F51 N Application currency code
The following output parameters are returned during "read transaction log" process:
—— An integer (n) representing the number of items in transaction logs;
—— A code that is returned;
—— Binary strings containing transaction log items.
Transaction log is defined in the form of recording list. The first record contains the last
(transaction) record written into file. Given the length of each record is M, Table H.6 describes
how the transaction log is defined.
Table H.6 Definition of Transaction Log
Byte Transaction log
0 The last item of transaction log
M The second last item of transaction log
2M The third last item of transaction log
… …
Table H.7 describes the format of each transaction log item.
Table H.7 The format of transaction log item
Byte Data element
3 Transaction date
3 Transaction time

6 Authorized amount
6 Other amount
2 Terminal country code
2 Transaction currency code
20 Merchant name
1 Transaction type
2 Application transaction counter (ATC)
The procedure of reading transaction log is as follows:
1. Card reader selects card application. If the returned code from card application is not
"successful", the card reader will terminate the process of reading transaction log and
generate the return code "card not accepted". Otherwise, the FCI data from SELECT
command indicates the transaction log is existed or not and maximum number to be
recorded potentially;
2. Card reader sends GET DATA command to get transaction log format (Through tag
"9F4F"). Table H.8 describes the applicable commands;
Table H.8 Command Format for Acquiring Transaction Log Format
Code Value
CLA 80
INS CA
P1 9F
P2 4F
Le 00
3. If the returned status bit of GET DATA command is not "9000", the card reader will
generate return code "card not accepted" and terminate "read transaction log" process;

4. Card reader verifies the log format (tag "9F4F"). If that is not exist, the card reader will
generate return code "card not accepted" and terminate "read transaction log" process;
5. Card reader checks the log format contains the tags that are required to display. If they are
not contain the required tags, the card reader will generate return code "card not accepted"
and terminate "read transaction log" process;
6. Card reader sends "read record" command to read the next record in transaction log (files
with short file identifier (SFI) equals to "OB"). Please refer to Table H.9 for the command
format for acquiring log items;
Table H.9 Command Format for Acquiring Log Items
Code Value
CLA 00
INS B2
P1 n (Record No.)
P2 5C
Le 00
7. If the returned status bit is not "9000" or "6A83", the card reader will generate return code
"card not accepted" and terminate "read transaction log" process;
8. If card reader returns the status bits "6A83", it indicates the card reader has read all
meaningful records from card transaction log;
9. If the length of returned data is not as expected, the card reader will generate return code
"card not accepted" and terminate "read transaction log" process; If the length of returned
data is as expected, the card reader will copy the response message to the output string of
transaction log;
10. Card reader continues to read the next log item until all transaction records are read.
H.3.2.2 Scrolling Display for Transaction Log
Card reader uses "display transaction log" to display transaction logs from card through "read
transaction log" processing.
There are 2 input parameters are used for the display transaction log processing:
—— An integer (n) representing the number of items in transaction log;

—— A binary string of at least 200 bytes that contains transaction log items.
The number of transaction log items is defined by FCI tag and it indicates the size of transaction
log. Please refer to Appendix B.1 in Part 3 of UnionPay Integrated Circuit Card Specifications -
Basic Specifications for relevant definition.
The only output parameter in "display transaction log" process is the return code. The value of
this return code is "successful" or "failed".
The card reader performs the following actions to display transaction log:
1. If the number of transaction log items is "0", card reader will prompt cardholder that there
is currently no information in transaction log and terminate the display transaction log
process;
2. If there is information in transaction log, card reader will get the following information
from each transaction log item:
—— Transaction date;
—— Transaction time;
—— Authorized amount;
—— Other amount;
—— Terminal country code;
—— Transaction currency code;
—— Merchant name;
—— Transaction type;
—— Application Transaction Counter (ATC).
3. If bit b8 and b7 of cryptogram information data (CID) are set to ‘00', the card reader will
refuse the transaction for this record and will not display its transaction log details. The
card reader will continue to process the next item;
4. It is recommended the card reader should structure its display string to contain the
following data elements:
—— Transaction date;
—— Transaction currency code: card reader should convert currency code from
numeric code to letter code before displaying it to cardholders (and should be in
accordance with ISO 4217);
—— Authorized amount: including the decimal.
Display string should be converted into following format: Date--Currency--Amount.
Then card reader will process the next item.

Part II Debit Credit Application Card Specification

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Part II Debit Credit Application Card Specification

Uploaded by

Copyright:

Available Formats

UnionPay Integrated Circuit Card Specifications

Part II Debit/Credit Application Card Specification

1 APPLICATION SCOPE ...................................................................................................... 2

3.1 FUNCTION OVERVIEW ....................................................................................................... 4

3.1.1 Application Selection (Mandatory) .................................................................... 4

3.1.2 Application Initialization/Read Application Data (Mandatory) ........................ 4

3.1.3 Offline Data Authentication (Optional) ............................................................. 4

3.1.4 Processing Restriction (Mandatory) .................................................................. 5

3.1.5 Cardholder Verification (Optional) .................................................................... 5

3.1.6 Terminal Risk Management (Mandatory) .......................................................... 5

3.1.7 Terminal Action Analysis (Mandatory) .............................................................. 5

3.1.8 Card Action Analysis (Mandatory) .................................................................... 6

3.1.9 Online Processing (Optional) ............................................................................ 6

3.1.10 Transaction Completion (Mandatory)................................................................ 7

3.1.11 Issuer- to-Card Script Processing (Optional) .................................................... 7

3.2 MANDATORY AND OPTIONAL FUNCTIONS ......................................................................... 8

3.2.1 Card Function Requirements ............................................................................. 8

3.2.2 Command Support Requirement ...................................................................... 10

4 APPLICATION SELECTION .......................................................................................... 12

4.1 CARD DATA .................................................................................................................... 12

4.2 TERMINAL DATA ............................................................................................................. 14

4.3 COMMAND ...................................................................................................................... 15

4.4 ESTABLISH CANDIDATE APPLICATION LIST ..................................................................... 16

4.4.1 Directory Selection Method ............................................................................. 16

4.4.2 AID List Selection Method ............................................................................... 17

4.5 APPLICATION IDENTIFICATION AND SELECTION .............................................................. 18

4.6 FLOW CHART .................................................................................................................. 19

4.7 SUBSEQUENT RELATED PROCESSING .............................................................................. 20

5 APPLICATION INITIALIZATION ................................................................................. 21

5.1 CARD DATA .................................................................................................................... 21

5.2 TERMINAL DATA ............................................................................................................. 22

5.3 COMMAND ...................................................................................................................... 22

5.4 PROCESSING FLOW ......................................................................................................... 23

5.5 PRIOR RELATED PROCESSING ......................................................................................... 24

5.6 SUBSEQUENT RELATED PROCESSING .............................................................................. 24

6 READ APPLICATION DATA........................................................................................... 26

6.1 CARD DATA .................................................................................................................... 26

6.2 TERMINAL DATA ............................................................................................................. 27

6.3 COMMAND ...................................................................................................................... 27

6.4 PROCESSING FLOW ......................................................................................................... 27

6.5 PRIOR RELATED PROCESSING ......................................................................................... 27

6.6 SUBSEQUENT RELATED PROCESSING .............................................................................. 27

7 OFFLINE DATA AUTHENTICATION ........................................................................... 28

7.1 KEY AND CERTIFICATE .................................................................................................... 28

7.2 DETERMINING THE METHOD OF OFFLINE DATA AUTHENTICATION ................................. 28

7.2.1 Card Data ........................................................................................................ 28

7.2.2 Processing ........................................................................................................ 29

7.3 STATIC DATA AUTHENTICATION (SDA) ........................................................................... 29

7.3.1 Card Data ........................................................................................................ 29

7.3.2 Terminal Data .................................................................................................. 32

7.3.3 Command ......................................................................................................... 32

7.3.4 Processing Flow ............................................................................................... 32

7.4 DYNAMIC DATA AUTHENTICATION (DDA) ..................................................................... 33

7.4.1 Card Data ........................................................................................................ 33

7.4.2 Terminal Data .................................................................................................. 34

7.4.3 Command ......................................................................................................... 35

7.4.4 Processing ........................................................................................................ 35

7.5 PRIOR RELATED PROCESSING ......................................................................................... 37

7.6 SUBSEQUENT RELATED PROCESSING .............................................................................. 37

8 PROCESSING RESTRICTION ....................................................................................... 39

8.1 CARD DATA .................................................................................................................... 39

8.2 TERMINAL DATA ............................................................................................................. 39

8.3 PROCESSING ................................................................................................................... 40

8.3.1 Application Version Number Check ................................................................. 40