JR/T Translated English of Chinese Standard: JR/T

Transcription

1 Translated English of Chinese Standard: JR/T JR FINANCIAL INDUSTRY STANDARD OF THE PEOPLE S REPUBLIC OF CHINA ICS A 11 Registration number: JR/T Replacing JR/T China financial integrated circuit card specifications - Part 6: Debit/credit application terminal specification 中国金融集成电路 (IC) 卡规范 - 第 6 部分 : 借记 / 贷记应用终端规范 JR/T How to BUY & immediately GET a full-copy of this standard? Search --> Add to Cart --> Checkout (3-steps); 3. No action is required - Full-copy of this standard will be automatically & immediately delivered to your address in 0~60 minutes. 4. Support: Sales@ChineseStandard.net. Wayne, Sales manager Issued on: February 05, 2013 Implemented on: February 05, 2013 Issued by: People s Bank of China Page 1 of 126

2 Table of Contents Foreword... 4 Introduction Scope Normative references Terms and definitions Symbols and abbreviations Terminal hardware requirements Memory Magstripe reader IC card reader Display Printer Clock Background communication module keyboard Password keyboard Terminal type General requirements Transaction Type Transaction input method Download management Debit/credit application function Functional overview Application selection Application initialization Read application data Offline data authentication Processing restrictions Page 2 of 126

3 7.7 Card verification Terminal risk management Terminal behavior analysis Card behavior analysis Online processing Issuer script processing Transaction end Terminal data Data element format conventions Terminal and acquirer datasheets Terminal data management requirements Financial transaction command Appendix A (Normative) Terminal data element encoding Appendix B (Normative) Transaction log read References Page 3 of 126

4 Foreword JR/T 0025 China financial integrated circuit card specifications is divided into the following parts: - Part 1: Electronic purse/electronic deposit application card specification (abolished); - Part 2: Electronic purse/electronic deposit application specification (abolished); - Part 3: Specification on application independent ICC to terminal interface requirements; - Part 4: Debit/credit application overview; - Part 5: Debit/credit application card specification; - Part 6: Debit /credit application terminal specification; - Part 7: Debit/credit application security specifications; - Part 8: Contactless specification independent of application; - Part 9: Electronic purse comprehensive application guide (abolished); - Part 10: Debit/credit card personalization guide; - Part 11: Contactless integrated circuit card communication specification; - Part 12: Contactless integrated circuit card payment specification - Part 13: Low-value payment specifications based on debit/credit application; - Part 14: Comprehensive application specification based on contactless low-value payment application; - Part 15: Electronic cash dual-currency payment specification; - Part 16: IC card internet terminal specification; - Part 17: Enhanced debit/credit application security specification. This part is part 6 of JR/T This part was drafted in accordance with the rules given in GB/T Page 4 of 126

5 China financial integrated circuit card specifications - Part 6: Debit/credit application terminal specification 1 Scope This part of JR/T 0025 describes the debit/credit transaction process from the perspective of the terminal, including the hardware requirements of the terminal, the processing details inside the terminal, the data elements used by the terminal, the command set supported by the terminal, and the like. This clause is applicable to financial terminals, point-of-sale terminals and other similar terminal devices that support the debit/credit application as specified in JR/T The objective user is mainly the terminal design, manufacture, application system research, development, integration and maintenance, and other departments (units) related to the application of the financial IC card. 2 Normative references The following files are essential to the application of this file. For the dated files, only the versions with the dates indicated are applicable to this file; for the undated files, only the latest version (including all the amendments) are applicable to this file. GB/T 2659 Codes for the representation of names of countries and regions (GB/T , ISO :1997, EQV) GB/T Codes for the representation of currencies and funds (GB/T , ISO 4217:2001. IDT) GB/T Bank card originated messages - Interchange message specifications-content for financial transactions (GB/T , ISO 8583:1987, IDT) GB/T Identification card - Integrated circuit(s) cards with contacts - Part 5: National numbering system and registration procedure for application identifiers (ISO/IEC :1994, NEQ) GB/T Banking - Personal identification number management and security - Part 1: Basic principles and requirements for online PIN handling in ATM and POS systems (ISO/IEC :2002, MOD) Page 8 of 126

6 JR/T 0001 Specification of point of sale (POS) terminal with magstripe card in bank JR/T China financial integrated circuit card specifications - Part 3: Specification on application independent ICC to terminal interface requirements JR/T China financial integrated circuit card specifications - Part 4: Debit/credit application overview JR/T China financial integrated circuit card specifications - Part 5: Debit/credit application card specification JR/T China financial integrated circuit card specifications - Part 7: Debit/credit application security specification JR/T China financial integrated circuit card specifications - Part 17: Enhanced debit/credit application security specification ISO/IEC 8859 (All parts) Preview information technology - 8-bit single-byte coded graphic character sets 3 Terms and definitions The following terms and definitions apply to this document Application Application protocols and related data sets between cards and terminals. Command A message sent by the terminal to the IC card that initiates an operation or requests a response. Cryptogram Encryption results. Page 9 of 126

7 system requirements. For each approved transaction, the transaction document can be printed offline, online, or via voice authorization. The format of printing documents is determined by each acquirer, but the following data shall be included: card number, application identifier AID, transaction date and time, and signature column. 5.6 Clock Terminals that can handle offline transactions shall be equipped with clock modules to provide local dates and times. Date is used for checking the validation date, expiration date, and certificate validity period in offline data authentication. Time can also be used to secure the transaction uniqueness identification and the input data used as application cryptogram generation algorithm. 5.7 Background communication module Terminals with online communication capabilities shall be equipped with modules that communicate with the acquirer host in the background. It is used to send transaction data packets to the host for authorization or to manage the terminal by the host. In accordance with the requirements of acquirer, it can use PSTN Modem dialing, GSM, GPRS, CDMA and TCP/IP and other means. Communication speed between the communication module and acquirer host shall be able to meet the requirements for the real-time transmission of IC card transaction data. 5.8 keyboard The terminal shall be equipped with a key pad for entering transaction amounts, selecting commands and executing functions. It supports the numeric keys, letter keys, command keys and function keys described in the EMV specification. The color and layout of command keys refer to the EMV specification. If a colored command key is used, the following color assignment is recommended. Command key color: confirm - green; cancel - red; clear - yellow. Page 15 of 126

8 6 General requirements 6.1 Transaction Type The transaction types as supported by JR/T 0025 debit/credit applications are as shown in Appendix A Transaction input method If the card is a magstripe card, the terminal swipes the magstripe card for transaction. If the card is a chip magstripe combined card, the terminal shall first read the chip card. If the device cannot read the chip or the card has no chip, the terminal reads the magstripe data for transaction. If the device can neither read the chip nor read the magstripe data, it can also enter the account by hand. It shall be in accordance with GB/T to set the corresponding POS input method of the terminal. The terminal can recognize and support the valid service codes in the magstripe data, and the issuer uses the service code to transfer the card attributes. If the magstripe card is first read and the service code begins with 2 or 6, it indicates that there is chip module in the card. If the terminal supports chip card transactions, it shall prompt to use chip card for transaction. If the terminal cannot accept the IC card or IC card cannot be used, then it is allowed to return to the magnetic card transactions. The terminal can support 11 to 19 bits long accounts in the card. 6.3 Download management Terminal shall be able to provide the functions of download, update and delete of such data as applications, keys and parameters. The downloaded communication port can be one or more of serial communication port (RS232, RS485), Modem communication port, USB port, infrared, GPRS, CDMA and TCI/IP network port or other types of communication ports. Download can also be local download or remote download. Terminal shall ensure the security of download control. Only authorized or approved party can download data to the terminal, and it is prohibited to change the contents in the terminal without authorization. The terminal shall Page 17 of 126

9 authentication (CDA), the terminal will be required to perform offline data authentication. Static data authentication (SDA) is mainly used to prevent unauthorized tampering card data, that is, verifying that the important application data on the card has not been fraudulently modified since the card was personalized. The terminal uses the issuer public key stored in the public key certificate of the card to verify the digital signature calculated by using the private key of the issuer. If the verification is correct, the terminal verifies that the card data has not been modified. Offline dynamic data authentication (DDA) is mainly used to prevent card data from illegally modified and verify the authenticity of the card itself. Dynamic data authentication is divided into standard dynamic data authentication (DDA) and combined dynamic data authentication (CDA). Both of the two approaches are similar to SDA in verifying card static data. In standard DDA, the terminal requires the card to use the digital signature generated from the dynamic data (transaction unique) and the IC card private key from the card and the terminal. The terminal verifies the digital signature with the IC card public key. If the verification is correct, it confirms that this card is not a pseudo-card that is generated by copying data from legitimate cards. In combined dynamic data authentication (CDA), the generation of dynamic signatures are combined with the application cryptogram generation in the card behavior analysis phase, to ensure that the application cryptogram is from a valid card. Processing restrictions (M) The terminal checks whether the application transaction is allowed to proceed by processing restriction. The checks include the application effective date, application expiration date, application version number, and other restrictions defined by the issuer. The issuer may use application use control (AUC) to limit whether the card is used domestically or abroad or whether it can be used for cash withdrawal, goods, services and cashback transactions. Cardholder verification (M) Cardholder verification is used to verify cardholder legitimacy to prevent the use of lost or stolen cards. The terminal determines which authentication method to use by checking the list of cardholder authentication methods (CVM) on the card. The CVM list establishes the priority order for cardholder authentication methods, providing the cardholder with a specific authentication method based on terminal capabilities and transaction characteristics. For Page 19 of 126

10 example, offline PIN verification, online PIN verification or signature, and the like. Terminal risk management (M) The terminal risk management check includes whether the transaction exceeds the minimum limit, whether the card account appears in the terminal abnormal file, whether the consecutive offline transaction limit is exceeded, whether the card is a new card, whether the merchant forces the transaction online, and whether the transaction is randomly selected online and so on. These risk management processes improve the security of transactions offline. Terminal behavior analysis (M) Terminal behavior analysis determines how to proceed with the transaction (offline approval, offline reject, or online authorization) based on offline data authentication, processing restriction, cardholder verification, terminal risk management results, and risk management parameters set on the terminal and card. Card behavior analysis (M) After the card receives the application cryptogram type requested by the terminal, the card behavior analysis is performed. The card risk management check determines whether to return the application cryptogram required by the terminal to reflect the card behavior analysis result and the card's judgment of the transaction result. Card behavior analysis includes the checking the last online transaction not completed, the last issuer certification failed, the last offline data authentication failed, whether to reach the number or amount frequency upper limit, and so on. The card can return cryptogram which is different from the type as requested by the terminal. If the terminal requests offline approval, the card may return to online processing or offline rejection; if the terminal requests online processing, the card may return an offline rejection; however, if the terminal requests an offline rejection, the can only return offline rejection. After the check is completed, the card generates the corresponding application cryptogram using the application data and the encrypted symmetric key on the card. And return it to the terminal. For offline approved transactions, the card returns the transaction certificate (TC); for online transaction processing, the card returns an authorization request cryptogram (ARQC); for offline rejected transactions, the card returns the application authentication cryptogram (AAC). The TC acts as a proof of approval of the transaction offline and ensures that the transaction data is not changed by the merchant or acquirer. Page 20 of 126

11 Online processing (O) If the card or terminal determines that the transaction requires online authorization and the terminal has the online capability, the terminal sends an online authorization message to the card issuer. This message contains the ARQC cryptogram, the data used to generate the ARQC, and an indicator indicating the result of the offline processing. The issuer authenticates the card by verifying the ARQC during the card authentication method (CAM) process. The issuer will consider the CAM results and offline processing results in its authorization decision. The authorization response message sent back to the terminal may include an authorization response cryptogram (ARPC) generated by the issuer (generated by encrypting the ARQC and the authorization response code with the card's security symmetric key). The response message may also include an issuer script which used by the issuer to update the data or status of the card after the card is issued. If the authorization response includes an ARPC and the card supports card issuer authentication, the card authenticates the issuer by verifying ARPC, to ensure that the online response is from the authentic issuer (or its agent). It is possible to require that the card be reset to some of the card's security-related parameters only if it has successfully completed the issuer authentication. This prevents illegitimate acquisition of card security features by simulating online processes, as well as by resetting the card counter and indicator by forgery approved transactions. If the issuer authentication fails, the subsequent card transaction will be required to send a request authorization online until the issuer is authenticated successfully. The issuer may set in the card to reject the transaction if the issuer authentication fails. Issuer script processing (O) If the issuer includes a script in the authorization response message, the terminal parses the script into a script command and sends it to the IC card. Before performing a script update, the card undergoes a security check to confirm that the script came from the true issuer and was not changed during the transfer. Script commands include application block, application unblock, card block, PIN unblock and change PIN. These commands do not affect the current transaction, mainly affecting the future transaction function of the card. Transaction end (M) Unless the transaction was terminated in the first few steps due to a processing exception, the terminal must end the transaction by performing this function. Page 21 of 126

12 AID list selection method Step 1: The terminal issues the SELECT command using the first AID in its list as the file name: Step 2: If the card is blocked or the SELECT command fails because the SELECT command is not supported (IC card returns status word SW1 SW2 = "6A81"), the terminal will interrupt the selection process; Step 3: If the SELECT command is executed successfully (SW1 SW2 = "9000" or "6283"), the terminal shall compare the DF name in the FCI returned by the AID and the card. The DF name shall be the same as the AID (including the length), or the DF name shall start with AID and be longer than the AID. If the DF name is longer than the AID, the card performs partial name selection processing. If the DF name is the same as the AID, the terminal shall go to step 4. If a partial name selection is made, the terminal shall proceed to step 6. If the terminal returns other status, it shall go to step 5; Step 4: If the SELECT command returns successfully (SW1 SW2 = "9000"), the terminal shall add the FCI information of the selected file to the candidate list and proceed to step 5. If the application is blocked (SW1 SW2 = "6283"), the terminal shall go straight to step 5, without adding the DF name to the candidate list; Step 5: The terminal sends the SELECT command to the card using the next AID in its list, and returns to step 3. If there is no remaining AID in the list, then the candidate list establishment is complete; Step 6: Corresponding to the AID list, the terminal also stores the application selection indicator (ASI) indicating whether multiple application matches are allowed. The terminal checks the indicator when selecting an application, and if the indicator shows that only a single application is allowed to match, the terminal will not add the file to the candidate list, but go to step 7; If multi-application matching is allowed and the application is not blocked (SW1 SW2 = "9000"), the terminal will add the FCI information to the candidate list, and goes to step 7. If multi-application matching is allowed but the application has already blocked (SW1 SW2 "9000"), the terminal shall proceed directly to step 7, without adding the FCI information to the candidate list. Step 7: The terminal uses the same command data as before, but sets the P2 parameter in the command to 02 ( select next ), send a SELECT command to the card, and if the IC card returns the status word SW1 SW2 = "9000", "62XX", Page 30 of 126

13 or "63XX", it goes back to step 3. If other status words are returned, the terminal goes to step Select transaction application After the terminal obtains the candidate application list jointly supported by the card and the terminal, it shall select an application to execute transaction Terminal automatically selects an application If the terminal does not support cardholder selection or cardholder confirmation, the terminal automatically selects the one with the highest priority and does not require confirmation. If more than one application has the highest priority, the terminal can select any of the applications or select the foremost application in the order they are listed Cardholder selects transaction application Terminal supports cardholder confirmation If the terminal does not support displaying the application list for the cardholder's selection but support cardholder application confirmation, it first provides the cardholder with the highest priority application for confirmation. If more than one application has the same priority, the terminal may select one of the applications in accordance with the order of precedence it encounters. If the cardholder confirms this selection, the terminal selects the application. If the cardholder does not confirm, the terminal provides the next highest priority application, until the cardholder confirms or no longer has more available applications. If the candidate application list has processed but the cardholder has not yet confirmed an application, the transaction is terminated Terminal supports cardholder selection Terminals that support cardholder selection give a list of applications to the cardholders in order of priority. If more than one application has the same priority, the terminals can arrange the order in the order of readout or on their own. The cardholder selects an application from the list. If the cardholder does not select application, the terminal will terminate the transaction Terminal processing description If there is no application in the candidate list, the transaction is terminated. Page 31 of 126

14 7.4.4 Processing flow The terminal determines which transaction data records to read from the card via the AFL. Each AFL entry (four bytes) represents a consecutive record in a file on the card. For each AFL entry (four bytes), beginning with the first record, the terminal sends a READ RECORD command to the card for each record in turn to read the record until the last record, to process all the AFL entries. The recognized transaction data read shall be stored on the terminal for transaction. If a tag with the correct TLV format but undefined specifications is read, the terminal shall save it for later use, and the terminal shall not terminate the transaction accordingly. For the record as indicated by AFL for offline data authentication, add their data to the offline authentication data list for offline data authentication. The terminal shall terminate the transaction if any of the following occurs during the read data processing: - The card returns the same tag twice or more in one or more records; - The card returns a tag in the record returned by the card in the GPO response; - There is missing data in the card; - Data format error; - READ RECORD command returns the status word which is not "9000". The transaction shall not be terminated because of the existence of one or more of the following: - The card has returned the cardholder name (5F20) but the length of the tag does not comply with JR/T ; - The card returned cardholder name extension (9F0B) but the length of the tag does not comply with JR/T ; - The card returned both the cardholder name (5F20) and the cardholder name extension (9F0B). Terminal processing flow chart is shown in Figure 6. Page 40 of 126

15 data indicated by DDOL. The card returns the signature dynamic application data in response Processing flow The standard DDA is implemented as follows, as described in detail in JR/T or clause 5 of JR/T Step 1: Get CA public key The terminal uses the public key index and RID in the card to uniquely identify and obtain the public key and related information stored in the terminal. Step 2: Get issuer public key The terminal uses the public key of the certificate authority to verify the issuer public key certificate. If the verification is correct, the issuer public key is taken out. Step 3: Get IC card public key The terminal uses the issuer public key to verify the public key certificate of the IC card. If the verification is correct, the terminal retrieves the public key of the IC card therein. Step 4: Dynamic signature generation The terminal sends an INTERNAL AUTHENTICATE command to the card, which contains a string of DDOL-specified data elements. If no DDOL is read from the card, the default DDOL from the terminal is used. DDA fails if the DDOL used does not contain an unpredictable number of tags ("9F 37"). The IC card generates signed dynamic application data by signing and encrypting the terminal dynamic data from the INTERNAL AUTHENTICATE command and the dynamic data from the card using the IC card private key on the card. The signature dynamic application data is returned to the terminal in response to the INTERNAL AUTHENTICATE command. Step 5: Dynamic signature authentication The terminal verifies the signed dynamic application data using the IC card public key, and if the verification is incorrect, the DDA fails. Step 6: DDA results - If all the above steps are successful, DDA is executed successfully; Page 48 of 126

16 key in the first three steps after performing the DDA, and performs the subsequent transaction processing. In the remaining execution of the CDA is performed in the processing of the GENERATE AC command. If the CDA authentication fails after the terminal receives the GENERATE AC response, refer to the relevant provisions of JR/T or clause 5 of JR/T , and the terminal must set the "combined dynamic data authentication/application cryptogram generation failed" bit to "1". If CDA verification fails after the first GENERATE AC: - If the card returns TC, the terminal shall reject the transaction; - If the card returns the ARQC, the terminal shall immediately execute the second GENERATE AC (AAC) and close the transaction. If it occurs after the 2 nd GENERATE AC, the terminal must reject the transaction Prior period related processing Application initialization Read AIP from card, and AIP indicates whether the card supports SDA, DDA, or CDA. Read application data The terminal reads the application data from the card, including the data required to support the offline data authentication method. The application file locator (AFL) and static data authentication tag list indicates the static data used for signature calculation in offline data authentication Follow-up related processing Terminal behavior analysis In the subsequent terminal behavior analysis, the "offline data authentication not implemented", "SDA failed", and "DDA failed" bits are used in the TVR to determine whether the transaction is rejected offline or processed online. When required to execute a CDA, the terminal sets the CDA command bit in the GENERATE AC command. Online processing If a CDA is required and the card returns an ARQC or TC in the 1 st GENERATE AC command, the terminal performs the remaining CDA operations. If the Page 53 of 126

17 usage control, issuer country code and application validation date, they will also be read out from the card Follow-up related processing Terminal behavior analysis In terminal behavior analysis, the terminal checks the issuer action code and the terminal action code to determine what must be done if the application version is inconsistent, the card is not valid, the card has expired, or the card does not support the requested service. 7.7 Card verification Cardholder verification is used to make sure that the cardholder is the owner of the card and that the card is not lost or stolen. The terminal performs the corresponding cardholder verification method by the list of cardholder verification methods (CVMs) provided by the processed card, in accordance with the card and terminal support capabilities to the cardholder verification method. This clause currently supports cardholder verification methods as follows: - Offline plain text PIN verification; - Online PIN verification - Signature; - CVM failed; - No CVM required; - Combination of signature and offline plain text PIN verification; - Cardholder ID presentation. The selection criteria in the list of cardholder authentication methods may include the type of transaction (cash withdrawal or consumption), the amount of the transaction, and the terminal performance. If a CVM fails, the list of cardholder authentication methods will indicate what the terminal will do next Terminal requirements The terminal must meet the following requirements in order to support cardholder verification: Page 58 of 126

18 established by the issuer, terminal performance and transaction characteristics. If the AIP indicates that the card supports CVM processing, and there is no CVM list data element in the card, the terminal sets the "IC card data missing" bit in the TVR to "1", and does not set the "cardholder verification performed" bit in the TSI, and ends the cardholder verification process. If the card application data file contains a CVM list and the AIP display card supports CVM processing, the terminal performs CVM list processing. The terminal processes each CVM list entry in the order shown in the CVM list. Step 1: Select CVM From the first CVM of the CVM list, determine one by one whether the CVM implementation conditions are met. If all of the following conditions are true, then the CVM is executed; - "CVM condition code" is understandable by the terminal; - The card data as required for the conditions is existed. For example, "application currency code" exists when the amount check is included in the CVM conditions; - The conditions specified in the CVM condition code are met. For example, if the CVM condition code is terminal supports this CVM, it shall indicate supporting the CVM processing in the terminal performance. If the conditions include amount judgement, then the transaction currency code shall be same as the application currency code. If one of the above conditions is not satisfied, the terminal decides whether to continue to the next CVM based on the "cardholder verification method code" Step 2: Process CVM If the conditions for CVM implementation are satisfied, the terminal processes this CVM, and the detailed processing flow of each CVM is as described in the subsequent clauses. If the terminal cannot identify this CVM, the "Unrecognized CVM" bit is set to 1 in the TVR, and the next processing is performed in accordance with the actions as described in CVM code. Step 3: CVM is successful Page 62 of 126

19 When CVM is an offline plaintext PIN, the transaction PIN is sent directly to the card in offline plain text PIN. When the IC card reader and the password keyboard are separated, for PIN security, the terminal shall encrypt the PIN on the password keyboard and decrypt the PIN when sending the PIN to the IC card reader, and then send it to the card through the VERIFY command for checking and comparison. If the terminal does not support offline PIN verification or the password keyboard does not work, the terminal shall: - Set the "PIN input requested but password keyboard is not provided or not working properly" bit in TVR to 1 ; - The CVM failed, and continue processing as defined by the CVM code. An attended terminal with a password keyboard may allow the PIN entry to be skipped before or after several unsuccessful PIN input verifications, to prevent a legitimate cardholder from having to repeatedly enter the wrong PIN code for a forgotten password, resulting in a card PIN block. If the merchant or cardholder instructs to skip the PIN input, the terminal shall: - Set the "PIN input requested, password keyboard provided, but no PIN input bit in TVR to 1 ; - The CVM failed, and continue processing by the actions as defined by the CVM code. - Do not set the "PIN retry limit exceeded" bit in TVR. When the terminal decides to request inputting an offline PIN, the terminal shall prompt for a PIN input, or otherwise check the PIN retry counter on the card. Step 1: Check "PIN retry counter" The terminal sends a GET DATA command to the card to read "PIN retry counter". The card returns the value of the PIN retry counter or the error response code. a) Return error response code If the return code is not "9000", it indicates that "PIN retry counter" is a card private data that the terminal cannot read. The terminal shall skip the "PIN retry counter" check, prompting for PIN input. b) "PIN retry counter" is 0 Page 65 of 126

20 Get the Application interchange profile (AIP) from the card to indicate whether the card supports cardholder verification. Read application data The terminal reads the list of cardholder verification methods (CVMs) from the card and the data used in other cardholder verification processes Follow-up related processing Terminal behavior analysis The terminal uses cardholder verification results, as well as the issuer action code and terminal action code to determine whether the transaction was rejected offline, sent an authorization request online, or approved offline. Card behavior analysis When the number of PIN attempts exceeds the limit, the card uses the cardholder verification results and the parameters in the application default behavior to decide whether to reject the transaction or to request online authorization. Online processing The authorization request message contains the cardholder verification results including the offline PIN verification result, which shall be considered in the authorization decision of the issuer. Online authorization message does not include offline PIN. If the CVM executed is an online PIN, the authorization request message will include an encrypted online PIN. Issuer script command processing The PIN CHANGE/UNBLOCK command can be used to reset the PIN retry counter to equal the number of PIN retry limit, and change the reference PIN. The APPLICATION UNBLOCK command can be used to unblock applications that are blocked in the cardholder verification process. Transaction end After an unsuccessful attempt to obtain authorization online, the card uses the parameters in the cardholder verification results and application default behavior to decide whether to reject the transaction. Page 72 of 126

21 Transaction status information (TSI) maintenance are defined by the specific application. If the log exists, the terminal minimum limit check will use this log Outline the functions the terminal performs during the transaction. In online authorization and clearing messages, this data element is not provided, but the terminal uses this data element to indicate that terminal risk management has been performed Command The terminal gets the last online application transaction number register (tag "9F13") and the application transaction counter (tag "9F36") from the card using the GET DATA command. The P1 and P2 parameters of the command are set to the tag of the data to be read. If the data is successfully read, the card returns "9000". The response data contains the data to be read in the TLV format Exception file check If the terminal exception file exists, the terminal checks whether the application primary account is in the exception file list. If the card appears in an exception file, the terminal will set Card appeared in terminal exception file bit in the TVR to Merchant forced transactions online For terminals having online capabilities, merchants can force the current transaction to be processed online. If the merchant forces transaction online, the terminal sets the "merchant forced transaction online" bit in the TVR to "1" Minimum limit The minimum limit is used to request online authorization when the current transaction amount of the transaction or the accumulative amount of multiple transactions over the same card exceeds a certain value. If the terminal does not support the transaction log, the terminal directly compares the authorization amount with the minimum limit. If the transaction authorization amount is greater than or equal to the minimum limit, the terminal sets the "transaction exceeds minimum limit" bit in TVR to 1. Even though the minimum limit is 0, the terminal performs the same check, which results in the "transaction exceeds minimum limit" bit in the TVR for all transactions set to 1. If the terminal supports the transaction log, the terminal looks for a transaction record in the transaction log that is identical to the current transaction in both PAN and PAN serial numbers (if both the terminal transaction log and the card Page 74 of 126

22 Threshold of bias random selection 40 Random selection target percentage 20% Maximum target percentage of bias random selection 50% Case 1: The transaction amount is 20. Because the transaction amount is less than the bias random selection threshold, a random selection is performed. Compare terminal random number and target percentage. Because the random number (25) is greater than the target percentage (20), the transaction is not selected for online processing. Case 2: The transaction amount is 60. This amount is greater than the bias random selection threshold, but less than the terminal minimum limit. Therefore, the application bias random selection is performed. The transaction amount is 20 higher than the threshold, which is 1/3 of the difference between the terminal minimum and the threshold ( = 60). Therefore, add one third (50% - 20% = 30%, 30% x 1/3 = 10%) of the difference between the maximum target percentage and the target percentage to the target percentage, resulting in a transaction target percentage of 30% (20 % + 10% = 30%). Terminal random number is 25, which is less than the transaction target percentage (30), so the transaction is selected for online processing. Case 3: The transaction amount is 150. Because the amount is greater than the terminal minimum limit, the transaction is not randomly selected, but subject to online processing by minimum limit check Frequency check Online terminals that support offline transactions must support frequency checks, requiring the card to request an online transaction after a consecutive number of offline transactions. The process is as follows: The terminal shall perform a frequency check if there is a floor limit for consecutive offline transactions (LCOL, tag "9F14") and an upper limit of consecutive offline transactions (UCOL, tag "9F23") read from the card during the read application data phase. If LCOL and UCOL do not exist, the terminal skips the frequency check. Page 76 of 126

23 The terminal sends a GET DATA command to the card requesting the last online ATC register and ATC, and the card returns the data in the command response. If it is not possible to get these two data objects from the IC card using the GET DATA command, the terminal shall set both the "consecutive offline transaction floor limit exceeded" and "consecutive offline transaction upper limit exceeded" bits in TVR to 1, and end the frequency check. If the last online ATC register and ATC are successfully obtained, the terminal performs as follows: - If the difference between ATC minus last online ATC register is greater than the floor limit of consecutive offline transactions, the terminal sets " consecutive offline transaction floor limit exceeded " bit in TVR to 1 ; - If the difference between the ATC minus last online ATC register is greater than the upper limit of consecutive offline transactions, the terminal sets " consecutive offline transaction upper limit exceeded " bit in TVR to New card check The terminal performing the frequency check shall also perform a new card check. If the last online ATC register value is 0, the terminal sets the "new card" bit in the TVR to 1. For the card used for the first time, sets the corresponding flags in TVR to request transaction online processing. The "new card" bit in TVR cannot be set to 1 if the GET DATA command failed to retrieve the value of the last online ATC register. Page 77 of 126

24 - The primary account used to check the terminal exception files; - If there is a consecutive offline transaction upper and floor limit on the card, they are used for terminal frequency check Follow-up related processing Terminal behavior analysis The terminal decides what to do based on the settings of the card and terminal if: - Card appears in the terminal exception file; - Merchants forced transactions online; - Transaction minimum limit exceeded; - Transactions are randomly selected for online processing; - Frequency check transaction count limit exceeded; - New card. 7.9 Terminal behavior analysis In the process of terminal behavior analysis, the terminal respectively applies the rules set by the issuer in the card and the acquirer in the terminal to determine the result of the offline processing, so as to determine whether the transaction can be approved offline, or rejected offline or authorized online. Terminal behavior analysis includes two steps: - Check offline processing results - The terminal checks the offline processing results in TVR to determine whether the transaction is approved offline, rejected offline, or requested online authorization. The terminal of the process needs to compare the TVR with the rule set by the issuer in the card - issuer behavior code (IAC) and the rule set by the acquirer in the terminal - terminal action code (TAC); - Request cryptogram processing - The terminal requests the corresponding application cryptogram in accordance with the judgment result of step Card data The terminal behavior analysis involves card data in Table Page 80 of 126

25 default value is used if TAC-online does not exist. If any corresponding bit of IAC-online and TVR is set to "1" at the same time, then the terminal: - Set the P1 parameter that generates the GENERATE AC command to the authorization request cryptogram (ARQC) for the online authorization request; - Perform the step of requesting application cryptogram. For an online only terminal, the terminal does not have to compare IAC-online and TAC-online with TVR if it has not been decided to reject offline in steps 1 and 2, but directly in accordance with the conditions that any corresponding bits of IAC-online or TAC-online and TVR are set to "1" at the same time to perform processing, by request online to continue transaction. Step 4: Use IAC-default and TAC-default to compare with TVR if the terminal is offline only or when there is a reason that the terminal with online processing cannot come online. If IAC-default does not exist, the default value FFFFFFFFFF is used, and if TAC-default does not exist, the default value of is used. If any of the corresponding bits of the comparison result are both 1 at the same time, then the terminal: - Set the authorization response code to Z3 (cannot be online, offline rejected), only offline terminal authorization response code is set to Z1 ; - Set the P1 parameter that generates the GENERATE AC command to request AAC; - Perform the step of requesting application cryptogram. For an online only terminal, it can choose to process the normal TAC/IAC-default or to skip the TAC/IAC-default processing when it cannot be brought online. Terminals that skip TAC/IAC-default processing shall process TAC/IAC-default to match TVR directly, and request AAC on the second GENERATE AC. For terminals that normally process TAC/IAC- defaults, application cryptogram shall be generated based on the matching results between TAC/IAC- defaults and the TVR, and only online terminals may complete the transaction offline. Step 5: If there is no case where the corresponding bit is "1" at the same time in the above comparison, then the terminal: - Set authorization response code to Y1 (offline approval); Page 83 of 126

26 The terminal reads the application data from the card. This data includes card risk management data object list 1 (CDOL1) and issuer action code (IAC). Offline data authentication, restriction processing, cardholder verification and terminal risk management Depending on the processing result, these offline functions set the corresponding bit in the terminal verification result (TVR). In the terminal behavior analysis, the transaction processing is decided by comparing the TVR with the bits corresponding to the issuer action code (IAC) and the terminal action code (TAC). In the offline data authentication process, the terminal decides whether to perform combined dynamic data authentication (CDA). If CDA is to be performed, the terminal saves this information to correctly set the reference control parameters in the 1 st GENERATE AC command Follow-up related processing Card behavior analysis In card behavior analysis, the card performs additional risk management to decide whether or not to agree with the terminal's decision to approve or request filming in the terminal's behavioral analysis Card behavior analysis Card behavior analysis allows issuers to conduct internal risk management, such as frequency check. The risk management in this step includes: - Check the last transaction; - New card check; - Frequency counter check. Card behavior analysis shall follow the provisions of clause 14 of JR/T Card data The following is a description of the data related to card behavior analysis on the card. A description of these data can be found in Appendix A.1 of JR/T Page 86 of 126

27 If the card returns ARQC, the terminal sends an online message to the host, including ARQC. Transaction end If online processing is required but the terminal cannot send message online, it shall perform additional terminal and card processing. Terminal use the issuer action code IAC-default and terminal action code TAC-default to perform additional analysis (similar to terminal behavior analysis), to determine the type of cryptogram (AAC or TC) required on the second GENERATE AC command Online processing Online processing allows the issuer background to perform authorization approval or transaction rejection based on the background based risk management parameter check. In addition to the traditional online fraud and credit checks, the issuer background authorization system can also use card-generated dynamic cryptogram for online card authentication, and consider the results of offline processing in authorization decisions. The return data of the issuer may include a post-issue update command issued by the card and a cryptogram generated by the issuer, where the cryptogram may be used to authenticate the validity of the issuer by the card, and this process is called issuer authentication Card data The GENERATE AC command response data returned from the card is encoded in either format 1 or format 2 as described in the data domain of Appendix B.6.4 (Response messages) of JR/T If the response data is in format 1, the range contains the data listed in Table 28. Table Online processing - 1 st GENERATE AC response data Data element Cryptogram information data (CID) Application transaction counter (ATC) Application cryptogram (AC) Issuer application data Descriptions Contain an indicator indicating the cryptogram type returned by the card, the highest two bits of which are 10, meaning that ARQC is returned The transaction total number counter executed after the application is implanted in the card 8-byte cryptogram value Include the private data of the issuer that needs to be sent to the issuer Page 89 of 126

28 - The cryptogram information data returned by the card indicates that the ARQC was returned; - Terminal has online processing capability. Step 3: The terminal must terminate the transaction if any of the following is true: - Terminal requests to application authentication cryptogram CAAC) but the card returns ARQC or TC; - Terminal requests ARQC but the card returns TC. Step 4: If any of the following conditions occur, the terminal must go to the transaction end function described later: - CDA was executed but the result failed; - Card responds AAC or TC; - Card responds ARQC but the terminal has no online processing capability Online response In the online response processing phase, the terminal receives the online response from the issuer host and decides whether the issuer authentication shall be performed: - If both of the following two conditions are met at the same time, the terminal will authenticate the issuer as described in Online authorization response contains the issuer authentication data; Application interchange profile (AIP) displays that the card supports issuer certification. - If any one of the following conditions is met, the terminal will proceed with transaction end. Online authorization response does not include the issuer authentication data; Application interchange profile (AIP) indicates that cards do not support issuer authentication. Page 92 of 126