Book C-5 Kernel Specification
EMV® Contactless Specifications for Payment Systems Book C-5 Kernel 5 Specification Version 2.11 June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11
Legal Notice
The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely respons ible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party’s infringement of any intellectual property rights in connection with the EMV® Specifications. June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11
Revision History
The following changes have been made to Book C-5 since the publication of version 2.10. Change bars are used in this specification to denote the sections that have been updated. Some of the numbering and cross references in this specification have been updated to reflect the modifications made in the new version. In addition to the below, minor editorial clarifications and corrections may be added for readability. No. Revision Date Chapter 1 June, 2023 3.4.1.2 2 June, 2023 2.4.1 2.4.2 3 June, 2023 4 June, 2023 5 June, 2023 Annex B 3.3.1.3 3.3.1.4 4.3 2.3 3.8.2.1 6 June, 2023 3.7.1.1 3.10.3.4 7 June, 2023 3.2 3.11 and others Contents of Revision Application Primary Account Number (PAN) (Tag ‘5A’) is added as a mandatory Data Element (SB263) Random Transaction Selection is added as an option which the Reader provider may choose in the implementation (SB266) Correct Tag values for data elements Transit Agent ID and Transit Related data. (SB269) Change the requirements when the Status Word ‘6F00’ is returned to Get Processing Options command (SB286) Change the requirements to provide a Try Another Interface Outcome if the terminal supports the contact interface (SB290) Add the supplement for the transaction result of the following process.
- Terminal Action Analysis
- Issuer Update Processing (SB291) Remove the feature of Torn Transaction Recovery (SB292) June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2. 1. 1. 1. 1. 1. 1. 1. 2. 2.1. 2.1. 2. 2. 2. 2.4. 2.4. 3. 3. 3. 3. 3. 3.5. 3.5. 3.5. 3.5. 3.5. 3. 3.6. 3.6. 3.6. 3. 3. 3.8. 3.8. 3.8. 3.8. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 3. 3.9. 3.9. 3.9. 3. 3.10. 3.10. 3.10. 3.10. 3.10. 3. 3.11. 3.11. 3.11. 3. 3.12. 3.12. 3.12. 3.12. 3.12. 3.12. 3.12. 3.12. 3.12. 3.12. 4. 4. 4. 4. 4. A. A. A. A. A. A. A. A. June 2023 Page v EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 A. Table 4-4: Data Objects Included in Response to GET PROCESSING OPTIONS.. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.エラー! ブックマークが定義されていません。 Requirement – Read Application Data エラー! ブックマークが定義されていません。 Requirement – Account Data Verificationエラー! ブックマークが定義されていません。 Requirement – Transaction Recovery Completionエラー!ブックマークが定義されていませ ん。 Requirement – Reset Recovery Contextエラー! ブックマークが定義されていません。 June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 1
Introduction
This chapter contains information that helps the reader understand and use this specification. 1.1
Scope
This document, the EMV Contactless Specifications for Payment Systems, Kernel 5 Specification, describes one of several Kernels defined for use with Entry Point.
1.2 Audience This specification is intended for use by reader providers and financial institution staff responsible for implementing financial applications.
1.3 Volumes of the Contactless Specifications This specification is part of a multi-volume set: Book A: Architecture and General Requirements Book B: Entry Point Specification Book C-n: Kernel Specifications Book E: Security and Key Management EMV L1 Contactless: EMV Contactless Interface Specification 1.4 Reference Materials The following specifications and standards contain provisions that are referenced in this specification. The latest version shall apply unless a publication date is explicitly stated. If any provision or definition in this specification differs from those in the listed specifications and standards, the provision or definition herein shall take precedence. [EMV] EMV Integrated Circuit Card Specifications for Payment Systems, including: June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 1 Introduction 1.5 Overview [EMV Book 1] [EMV Book 2] [EMV Book 3] [EMV Book 4] EMV Integrated Circuit Card Specifications for Payment Systems, Book 1, Application Independent ICC to Terminal Interface Requirements EMV Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management EMV Integrated Circuit Card Specifications for Payment Systems, Book 3, Application Specification EMV Integrated Circuit Card Specifications for Payment Systems, Book 4, Cardholder, Attendant, and Acquirer Interface Requirements 1.5 Overview This volume includes the following chapters and annexes: Chapter 1 contains general information that helps the reader understand and use this specification. Chapter 2 provides an overview of the Kernel 5 approach, including implementation/acquirer options and a high level transaction flow description. Chapter 3 specifies transaction processing for Kernel 5. Chapter 4 lists and describes the APDU commands used by Kernel 5. Annex A defines data elements that are specific to Kernel 5. Annex B is a dictionary of data elements used by Kernel 5 during the transaction processing. Annex C lists data elements that are required in the transaction record for approved, declined, and online requested transactions. Annex D defines the default Terminal Action Codes used by Kernel 5. Annex E is a glossary of terms and abbreviations used in this specification. June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 1 Introduction 1.6 Conventions 1.6 Conventions Table 1-1: Conventions used for data format Convention Meaning a an ans b cn n n y YYMMDD x ‘x’ “abc” var. Alphabetic Alphanumeric Alphanumeric Special Binary Compressed Numeric Numeric Numeric value of y digits (Example n 12 means 12 digits numeric value) Year, Month, Day Numeric value in decimal Numeric value in hexadecimal Data string Variable value For data elements which have multiple bytes in this specification, the first byte or byte 1 is the leftmost byte, while the last byte is the rightmost byte.
1.7 Terminology Table 1-2: Terminology Terminology Shall, “is mandatory” Should, may, can, “is optional” if test_condition then action_true else action_false and or = N/A Meaning Denotes a mandatory requirement. Denotes an optional requirement. Denotes a conditional test action, action_true is performed when test_condition result is true, action_false is performed when test_condition result is false. Logical AND which connects two conditional requirements Logical OR which connects two conditional requirements Logical comparison of two values Not applicable June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach This section is a high-level description of Kernel 5 features, capabilities, and processes. Further details about the Transaction Flow and its implementation can be found in Section 3.
2.1 Two Transaction Modes Kernel 5 shall always support EMV Mode and Legacy Mode.
2.1.1 EMV Mode EMV Mode is designed for Chip Grade payment infrastructures
The support of EMV Mode is mandatory on the Kernel side (Acquirer). The card will select to conduct the transaction in EMV Mode when the card supports it. The EMV Mode has many similarities with the transaction flow designed for contact EMV chips and defined in [EMV]. It is however simplified and adapted for contactless ergonomics. Here are the main features:
- Online/offline capability: EMV Mode transactions can be completed either online or offline. When completed online, the card is normally not informed about the final transaction outcome.
- Offline Data Authentication: The kernel shall support CDA when at least one of the conditions below is fulfilled: o the Kernel is offline-capable; o the Kernel is installed in a transit reader (where Cardholder Verification is bypassed); o the Kernel accepts On-Device CVM verification. Other data authentication methods (SDA, DDA) are not supported.
- Online Data Authentication: An ARQC cryptogram is generated by the card and verified by the Issuer host system.
- Cardholder Verification: The card determines the CVM requirement based on issuer preference and acquirer requirement and the Kernel performs the selected CVM. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.1 Two Transaction Modes 2.1.2 Legacy Mode Legacy Mode is available for Chip Grade acquirers to satisfy specific market requirements. Please refer to payment system rules for further details. Here are the main features:
- Online/offline capability: Legacy Mode transactions are always authorised online. The card is not informed about the final transaction outcome.
- Offline Data Authentication: N/A
- Online Data Authentication: An ARQC cryptogram is generated by the card and verified by the Issuer host system.
- Cardholder Verification: If the amount exceeds the CVM Required Limit, the Kernel analyses the CVM List from the card to determine the CVM requirement. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.2 Transaction Processing 2.2 Transaction Processing The transaction processing is summarised below. 1. Entry Point determines the most relevant Combination {ADF Name, AID, Kernel ID, Application Priority Indicator} to process the transaction, based on Reader Combinations and the card’s ADF parameters in the PPSE Response (Application Priority Indicator, Kernel Identifier). 2. Entry Point activates the Kernel to process the transaction. The reader provides transaction data and the relevant configuration parameters to the Kernel. a. Based on the card response to the SELECT (DF Name) command, the Kernel can determine whether it is a legacy card or not. 3. The Kernel sends the GET PROCESSING OPTIONS command to the card to initialise the card application. a. Card returns the Application Interchange Profile (AIP) and the Application File Locator (AFL). b. For non-legacy cards, the card response enables to detect that the card has selected the EMV Mode. 4. The Kernel reads the card data as indicated by the AFL. 5. The Kernel performs Terminal Risk Management, which consists of several verifications: a. Contactless Limit Check b. CVM Limit Check c. Floor Limit Check (EMV Mode only) d. Random Transaction Selection (EMV Mode only) e. Exception File Check (option only applying to EMV Mode) These verifications update the Terminal Verification Results (TVR). 6. The Kernel performs Processing Restrictions, which consists of several verifications: a. Application Usage Control (EMV Mode only) b. Application Expiration Date c. Application
Effective Date
These verifications update the Terminal Verification Results (TVR). June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.2 Transaction Processing 7. Based on the TVR value, as well as Terminal Action Codes (TAC) and Issuer Action Codes (IAC), the Kernel computes the first transaction outcome. a. If the outcome is a Decline, the transaction is declined offline and the Kernel provides a Declined Outcome to the Entry Point. b. In the case of Legacy Mode, unless the payment application declines the transaction, then the outcome is Online Authorisation. 8. The Kernel then completes the transaction in the following steps: a) If the transaction is in EMV Mode:
- The Kernel issues a GENERATE AC command including Combined Data Authentication (CDA) request when supported.
- If the card approves or sends the transaction for authorisation (TC/ARQC), the card response includes a CDA signature (if requested by the Kernel) as well as the decision of the card regarding the Cardholder Verification Method (CVM) to be applied.
- The Kernel verifies the CDA signature (if any) and if valid, executes the card decision (TC/ARQC) and CVM policy.The Kernel then provides an Approved or Online Request Outcome corresponding to the decision for this transaction to the Entry Point. b) If the transaction is in Legacy Mode:
- The Kernel issues a GENERATE AC command requesting an online authorisation (ARQC) without CDA.
- The card returns the ARQC cryptogram.
- If the CVM Required Limit is exceeded, the Kernel analyses the CVM list from the card to find an appropriate method.
- The Kernel provides an Online Request Outcome to the Entry Point for this transaction for online authorisation. 9. Optionally, if the transaction is in EMV Mode and the Transaction Outcome is Online Request, the reader may reactivate the Kernel when the online response from the Issuer contains any information. At this point, the card may still be in the field (e.g. “present-and-hold”) or requested to be presented again (e.g. “two presentments”).
- For “present-and-hold”: when returning the ARQC cryptogram, the card informs simultaneously the Kernel that it shall be maintained in the contactless field during the online authorisation. After receiving the online response, Issuer Scripts and/or Issuer Authentication Data can be transmitted to the card. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.3 High Level Transaction Flow
- For “two presentments”: when returning the ARQC cryptogram, the card informs simultaneously the Kernel that it supports a second presentment. After receiving the online response, the cardholder is asked by Entry Point to present the card again, and Issuer Scripts and/or Issuer Authentication Data can be transmitted to the card.
2.3 High Level Transaction Flow Figure 2-1 below illustrates the high level transaction flow of Kernel 5. The purpose is to provide a summarised overview of the normal Kernel 5 processing and is not prescriptive. Note that specific processes like Issuer Update is not represented in this figure which features only a nominal transaction flow. Details about each step of the transaction can be found in Section 3. June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.3 High Level Transaction Flow Figure 2-1: High-Level Sample Transaction Flow Transaction Flow Discovery Process handled by Entry Pont SELECT (PPSE) SELECT (DF) Legacy Yes Card? Yes GET PROCESSING OPTIONS Legacy mode supported? No Select Next (Card exception) READ RECORD(s) Terminal Risk Management: - Contactless Limit Check - CVM Limit Check - Floor Limit Check - Random Selection - Exception File Check (Card exception) Processing Restrictions - Application Usage Control - Application Expiration Date - Application Effective Date Legacy Mode, Online GENERATE AC (ARQC) Terminal Action Analysis EMV/Legacy Mode, Declined End Application (1st tap) EMV Mode, Approved/Online GENERATE AC (CDA) CARD REMOVAL TC/ARQC Declined AAC CVM Process (Legacy Mode) NOK Declined NOK (when terminal supports contact I/F) Try Another Interface Online Request ARQC CDA Verification CVM Process (EMV Mode) TC Approved NOK NOK June 2023
EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 2 Overview of the Kernel 5 Approach 2.3 High Level Transaction Flow online response Case of "present-and-hold" Correct FCI contain Issuer Script Template 1? No (tag ‘71’) Yes Issuer Script Commands Case of "two presentment" SELECT (ADF) Incorrect FCI contain Issuer Authentication Data (tag ‘91’) No or Issuer Script Template 2? (tag ‘72’) Yes 2nd GENERATE AC SW=9000 Prepare Outcome - SW≠9000 - incorrect format contain Issuer Script Template 2? No (tag ‘72’) Yes Issuer Script Commands Prepared Outcome is "Approved" Approved Prepared Outcome is "Declined" Declined End Application June 2023
EMV® Contactless Specifications for Payment Systems 2 Overview of the Kernel 5 Approach Kernel C-5 Specification v2.11 2.4 Implementation Options and Acquirer Options 2.4 Implementation Options and Acquirer Options 2.4.1 Implementation Options The provider of Kernel 5 will choose whether to support or not the following options in the Kernel 5 implementation:
- Offline Data Authentication
- This implementation option enables support of CDA to authenticate the card. CDA is only used for EMV Mode.
- Kernel 5 implementations for offline-capable readers, transit readers, or readers accepting On-Device CVM shall support this option.
- Exception File Check
- This implementation option enables Kernel 5 to check during the transaction whether the card appears in the Acquirer Exception File.
- Exception File Check is only used for EMV Mode.
- Implementations for transit readers shall support this option.
- The Data Exchange mechanism enable readers to update Acquirer Exception File. Readers supporting Exception File Check should support Data Exchange.
- The exact implementation of this option is left at the discretion of the implementer. It may, for instance, take advantage of the Data Exchange mechanism described in Book A.
- Random Transaction Selection
- This implementation option enables readers to select transactions randomly for online authorisation.
- Random Transaction Selection is only used for EMV Mode.
- Implementations for offline with online capable readers shall support this option.
- Issuer Update
- This implementation option enables to convey EMV data (Issuer Authentication Data and/or Issuer Scripts, which are/is optionally present in the Authorisation Response Message) to the contactless card, upon completion of the Authorisation process. June 2023 EMV® Contactless Specifications for Payment Systems 2 Overview of the Kernel 5 Approach Kernel C-5 Specification v2.11 2.4 Implementation Options and Acquirer Options
- An Issuer Update may be transmitted to the card in one of two forms: either as a single presentment of the card (i.e. card remains in the contactless field while the authorisation process is ongoing), or as a second presentment of the card after the authorisation. Readers supporting Issuer Update shall support both ergonomics, as the choice is indicated by the card.
- Issuer Update is only used for EMV Mode.
- Cardholder Verification Method The Kernel 5 shall support all Cardholder Verification Methods described in this specification except following case applies:
- If the Reader supports only Transit Reader, the Reader provider may choose whether to support or not the Cardholder Verification Method.
- If the Reader supports offline environment only, the Reader provider may choose whether to support or not the following Cardholder Verification Method in the Reader implementation: - Online PIN
- If the Reader supports ATM only, the Reader provider may choose whether to support or not the following Cardholder Verification Method in the Reader implementation: - Signature - On-Device CVM
- If the Reader supports Unattended Merchant Terminal only, the Reader provider may choose whether to support or not the following Cardholder Verification Method in the Reader implementation: - Signature - Online PIN 2.4.2 Acquirer Options In addition to the Implementation Options, which define the features for a specific Kernel 5 implementation, the Acquirer may also choose to support from these implemented features for deployment. The Acquirer Options are defined below: Acquirer Options are parameterised in the Combination Options parameter (see Annex A.3) or in the static Terminal Interchange Profile (see Annex A.9) for each supported Reader Combination.
- Legacy Mode June 2023 EMV® Contactless Specifications for Payment Systems 2 Overview of the Kernel 5 Approach Kernel C-5 Specification v2.11 2.4 Implementation Options and Acquirer Options
- This option activates Legacy Mode flow for the associated Reader Combination.
- Offline Data Authentication
- This option activates CDA for EMV Mode. The option shall be activated if any of the conditions below is true:
- the reader is offline-capable.
- the reader is a transit reader as configured in the Terminal Interchange Profile (see Section A.9).
- the reader accepts “On-Device CVM” as a Cardholder Verification Method in the Terminal Interchange Profile (see Section A.9).
- The option is available only if Offline Data Authentication (implementation option) is supported in EMV Mode.
- Exception File Check
- This option activates Acquirer Exception File Check during the transaction.
- The option is available only if Exception File Check (implementation option) is supported in EMV Mode.
- Random Transaction Selection
- This option activates Random Transaction Selection during Terminal Risk Management.
- The option is available only if Random Transaction Selection (implementation option) is supported in EMV Mode.
- Issuer Update
- This option activates Issuer Update to convey EMV data (Issuer Authentication Data and/or Issuer Scripts, which are/is optionally present in the Authorisation Response Message) to the contactless card, upon completion of the Authorisation process.
- The option is available only if Issuer Update (implementation option) is supported in EMV Mode. June 2023 EMV® Contactless Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing This chapter provides detailed transaction processing requirements for Kernel 5 including information related to EMV functions.
3.1 Kernel Activation When activated, Kernel 5 requires certain data elements to be available in order to process the transaction. A data element or flag may be:
- Static (Configuration parameter): The value of this data is persistent from one transaction to the next (See Table 3-1). Updates of the values are exceptional and always outside the scope of Kernel 5 processing. A static data element may be set: o per POS System (e.g. Terminal Country Code), or o per RID (e.g. CAPK key), or o per AID (e.g. static Terminal Interchange Profile)
- Dynamic (Transaction parameter): Per transaction, e.g. Amount, Authorised (Numeric) and Unpredictable Number (See Table 3-2). Requirement – Static Configuration Parameters 3.1.1.1 When the Kernel is activated, the reader shall provide to the Kernel the Configuration Data (see Table 3-1: Static Kernel Configuration Parameters) associated with the selected Combination. Requirement – Dynamic Transaction Parameters 3.1.1.2 When the Kernel is activated, the reader shall provide to the Kernel:
- The Dynamic Transaction Parameters (see Table 3-2: Dynamic Transaction Parameters); and
- FCI received from the card as per section 3.4 in [EMV CL Book B] (when applicable). June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.1 Kernel Activation Table 3-1: Static Kernel Configuration Parameters Name
Description
Varies Presence1 Format Specified Tag by On-Device CVM Indicates the limit for which contactless Contactless transactions can be conducted when CVM is On- AID O Transaction Limit Device CVM (EMV Mode only). Combination Options Defines some acquirer options for the combination, e.g. modes supported. AID M Used in Kernel 5 Terminal Risk Management CLiomnittactless Floor (sEuMppVorMtsoFdleooornLlyi)m. iPt rCehseecnkt iof rthReaCnodmombination AID C Transaction Selection. Used in Kernel 5 Terminal Risk Management. Contactless Indicates the limit for which contactless Transaction Limit transactions can be conducted when CVM is AID O other than On-Device CVM (EMV Mode), or when Transaction Mode is Legacy Mode. n12 Kernel 5 - b Kernel 5
- See A.3 n12 Kernel 5 - n12 Kernel 5
- CVM Required Limit Used in Kernel 5 Terminal Risk Management. AID O n12 Kernel 5
- Maximum Target Percentage to be Present if the Combination supports Random AID C Used for Biased Transaction Selection (EMV Mode only). Random Selection n2 EMV
- Length (bytes) 6 2 6 6 6 1 1 M = mandatory; C = conditional; O = optional June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.1 Kernel Activation Name Description Removal Timeout Target Percentage to be Used for Biased Random Selection Terminal Action Code
- Default Terminal Action Code
- Denial Terminal Action Code
- Online Terminal Interchange Profile (static) Threshold Value for Biased Random Selection Acquirer Identifier Merchant Category Code Present if the Combination supports Issuer Update as Acquirer Option (EMV Mode only). In case of Online Request with “Present and Hold” outcome, this parameter corresponds to the time after which cardholder is asked to remove the card. Value is given in units of 100ms. Present if the Combination supports Random Transaction Selection (EMV Mode only). Used in Kernel 5 Terminal Action Analysis (EMV Mode only). Used in Kernel 5 Terminal Action Analysis. Used in Kernel 5 Terminal Action Analysis (EMV Mode only). Defines the Cardholder Verification Methods and other reader capabilities (online capability, contact EMV capability) for the Combination. Present if the Combination supports Random Transaction Selection (EMV Mode only). Uniquely identifies the acquirer within each payment system. Classifies the type of business being done by the merchant, represented according to ISO 8583:1993 for Card Acceptor Business Code. Varies by AID AID AID AID AID AID AID POS POS Presence1 C C O O O M C M C Format n4 n2 b b b b n12 n 6-11 n 4 Specified Tag Kernel
- EMV
- EMV
- EMV
- EMV
- Kernel 5 See A.9 EMV
- EMV ‘9F01’ EMV ‘9F15’ Length (bytes) 2 1 5 5 5 3 6 6 2 June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.1 Kernel Activation Name Description Merchant Name and Location Terminal Country Code Terminal Type Transaction Currency Code Transaction Currency Exponent Certification Authority Public Key Indicates the name and location of the merchant. Indicates the country of the terminal, represented according to ISO 3166. Requested in CDOL1. Indicates the environment of the terminal, its communications capability, and its operational control. Indicates the currency code of the transaction according to ISO 4217. Requested in CDOL1. Indicates the implied position of the decimal point from the right of the transaction amount represented according to ISO 4217. Required to determine if Status Check is requested. Present (up to 6 different instances) if Offline Data Authentication is supported for at least one of the Combinations with this RID (EMV Mode only). Each CA Public Key in the list is composed of the following mandatory fields:
- CAPK Index (b, 1 byte)
- CAPK Modulus (b, max. 248 bytes)
- CAPK Exponent (b, 1 or 3 bytes)
- CAPK SHA-1 Checksum (b, 20 bytes) Varies by POS POS POS POS POS RID Presence1 M M M M M C Format ans n3 n 2 n 3 n 1 b Specified Tag EMV EMV ‘9F4E’ ‘9F1A’ EMV ‘9F35’ EMV ‘5F2A’ EMV ‘5F36’ EMV
- Length (bytes) var. 2 1 2 1 var. June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.1 Kernel Activation Table 3-2: Dynamic Transaction Parameters Name Description Amount, Authorised (Numeric) Amount, Other (Numeric) Authorisation Response Code (ARC) Issuer Authentication Data Issuer Script Template 1 Authorised amount of the transaction. Requested in CDOL1. Secondary amount associated with the transaction representing a cashback amount. Requested in CDOL1. Code that defines the disposition of a message. ARC shall be present if the Kernel is restarted after an Online Request Outcome. ARC shall not be present if it is a new transaction. Data sent to the card for online issuer authentication. Issuer Authentication Data may be present if the Kernel is restarted after an Online Request Outcome. Issuer Authentication Data shall not be present if it is a new transaction. Contains proprietary issuer data for transmission to the card before the second GENERATE AC command. Several occurrences of this data element may be present. Issuer Script Template 1 may be present if the Kernel is restarted after an Online Request Outcome. Issuer Script Template 1 shall not be present if it is a new transaction. Presence2 M M C O O Format Specified n12 EMV n12 EMV an2 EMV b EMV b EMV Tag ‘9F02’ ‘9F03’ ‘8A’ ‘91’ ‘71’ Length (bytes) 6 6 2 8-16 var. max. 128 2 M = mandatory; C = conditional; O = optional June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.1 Kernel Activation Name Issuer Script Template 2 Transaction Date Transaction Time Transaction Type Unpredictable Number Description Contains proprietary issuer data for transmission to the card after the second GENERATE AC command. Several occurrences of this data element may be present. Issuer Script Template 2 may be present if the Kernel is restarted after an Online Request Outcome. Issuer Script Template 2 shall not be present if it is a new transaction. Local date that the transaction was authorised. Requested in CDOL1. Local time that the transaction was authorised. Possibly requested in CDOL1. Indicates the type of financial transaction, represented by the first two digits of the ISO 8583:1987 Processing Code. Requested in CDOL1. Possible values are: - ‘00’ for a purchase transaction - ‘01’ for a cash advance transaction - ‘09’ for a purchase with cashback - ‘20’ for a refund transaction Value to provide variability and uniqueness to the generation of a cryptogram. Requested in CDOL1. Presence2 O M M M M Format b n6 n6 n2 b Specified EMV EMV EMV EMV EMV Tag ‘72’ ‘9A’ ‘9F21’ ‘9C’ ‘9F37’ Length (bytes) var. max. 128 3 3 1 4 June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.2 Transaction Initialisation 3.2 Transaction Initialisation During Transaction Initialisation, Kernel 5 initialises internal variables and performs verifications. Requirement – Transaction continuation 3.2.1.1 If Authorisation Response Code (Tag ‘8A’) is present in the Dynamic Transaction Parameters (see Table 3-2), Then the Kernel shall proceed with Requirement 3.2.1.2. Otherwise the Kernel shall proceed with Requirement 3.2.1.3.
3.2.1.2 If any of the following is present in the Dynamic Transaction Parameters (see Table 3-2), - Issuer Authentication Data (‘91’) - At least one occurrence of Issuer Script Template 1 (‘71’) - At least one occurrence of Issuer Script Template 2 (‘72’) Then the Kernel shall restore transaction data from the Online Transaction Context and proceed with Issuer Update Processing, as described in section 3.10. Otherwise the Kernel shall provide an End Application outcome as described in section 3.12.7. Requirement – SELECT response analysis 3.2.1.3 If the FCI is absent Or if the FCI is not parsed correctly (see table 45 in [EMV Book 1]) Or if the PDOL data element is absent, or present but empty, Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10. June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.2 Transaction Initialisation Requirement – Variable Initialisation 3.2.1.4 The Kernel shall reset the following data elements:
- Terminal Verification Results (Tag ‘95’) to ‘00 00 00 00 00’
- Terminal Compatibility Indicator (Tag ‘9F52’) to ‘00’, 3.2.1.5 The Kernel shall reset the following internal variables:
- Online Transaction Context
- Transaction Mode to ‘Undefined Mode’ Requirement – Terminal Compatibility Indicator 3.2.1.6 The Kernel shall set Terminal Compatibility Indicator (Tag ’9F52’) to ’02’ Requirement – Terminal Interchange Profile 3.2.1.7 The Kernel shall initialise a dynamic Terminal Interchange Profile (Tag ‘9F53’) from the value of the static Terminal Interchange Profile (static configuration parameter – no tag) and perform the following:
- Clear Byte 1 Bit 8 (“CVM required by reader”).
- If Issuer Update is not supported as an implementation option, Then clear Byte 2 Bit 8 (‘Issuer Update supported’). Note: The dynamic Terminal Interchange Profile (Tag ‘9F53’) is updated by the Kernel during subsequent processing. At this stage, the Kernel will detect whether the presented card is a legacy card, and if so, ensure that it has the capability to process such cards. June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.2 Transaction Initialisation Requirement – Legacy Mode Detection 3.2.1.8 If the PDOL contains Terminal Compatibility Indicator (Tag ‘9F52’), Then the Kernel shall proceed with section 3.3: Initiate Application Processing. Otherwise the card is a legacy card and the Kernel shall proceed with Requirement 3.2.1.9.
3.2.1.9 If the Combination Options indicates ‘Legacy Mode Supported’ for this AID, Then the Kernel shall set Transaction Mode to ‘Legacy Mode’ and proceed with section 3.3: Initiate Application Processing. Otherwise the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10. June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.3 Initiate Application Processing 3.3 Initiate Application Processing The PDOL provided by the card in response to the SELECT command contains a list of tags that the card requests to the reader. The reader provides the card with the PDOL-related data elements when issuing the GPO command to the card. Requirement – PDOL Processing and GPO Command 3.3.1.1 The Kernel shall process the PDOL and send the command data for the GET PROCESSING OPTIONS as described in [EMV Book 3].
3.3.1.2 If the PDOL requires a data element that is not recognised by the Kernel (not referenced in Annex B), Then the Kernel shall fill in the corresponding PDOL related data with zeroes. The Application Interchange Profile (AIP) and Application File Locator (AFL) returned by the card in response to the GPO command contain information on the card configuration and data records to be read. The card response may use either Format 1 or Format 2, as described in [EMV Book 3]. The Kernel detects that EMV Mode is selected by the card by checking the value of AIP returned by the card. The Kernel also ensures that the card supports CDA. Other AIP bits are not analysed by the Kernel. June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.3 Initiate Application Processing Requirement – GPO Response Analysis 3.3.1.3 If the Status Word returned by the card is ‘6F00’, Then the Kernel shall terminate the transaction and provide an End Application Outcome with the following Outcome parameter values: End Application:
- Start: N/A
- Online Response Data: N/A
- CVM: N/A
- UI Request on Outcome Present: Yes Message Identifier: '06' (“CARD ERROR”) Status: Ready to Read
- UI Request on Restart Present: No
- Data Record Present: No
- Discretionary Data Present: No
- Alternate Interface Preference: N/A
- Receipt: N/A
- Field Off Request: N/A
- Removal Timeout: Zero 3.3.1.4 If the Status Word returned by the card is different from ‘9000’ and ‘6F00’, Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10.
3.3.1.5 If the AIP (Tag ‘82’) is absent from the GET PROCESSING OPTIONS response, Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10. June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.3 Initiate Application Processing Requirement – GPO Response Analysis 3.3.1.6 If the Transaction Mode is equal to ‘Undefined Mode’, Then If the AIP (Tag ‘82’) returned by the card has Byte 2 Bit 8 set to ‘1’ (‘EMV Mode Selected’), And the Terminal Compatibility Indicator Byte 1 Bit 2 is set to ‘1’ (‘EMV Mode Supported’), Then the Kernel shall set Transaction Mode to ‘EMV Mode’. Else the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section3.12.10.
3.3.1.7 If the AFL (Tag ‘94’) is absent from the data returned to the GET PROCESSING OPTIONS response Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10.
3.3.1.8 If the AFL (Tag ‘94’) is present in the GET PROCESSING OPTIONS RESPONSE And its value is incorrectly formatted (e.g. not multiple of 4 bytes, invalid SFI value...), Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10.
3.3.1.9 If any of the conditions below is true:
- the Transaction Mode is equal to ‘Legacy Mode’
- the Transaction Mode is equal to ‘EMV Mode’ and Offline Data Authentication (implementation or acquirer option) is not supported
- the Transaction Mode is equal to ‘EMV Mode’ and the AIP (Tag ‘82’) indicates that CDA is not supported (Byte 1 bit 1 is ‘0’) Then the Kernel shall set TVR Byte 1 bit 8 (‘Offline Data Authentication was not performed’) to ‘1’. June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.4 Read Application Data 3.4 Read Application Data The Kernel uses the AFL to determine which records to request from the card. The Kernel does not need to process any data at this point, except to determine if all the mandatory data elements are present. Requirement – Reading Records 3.4.1.1 If the AFL has been provided by the card, the Kernel shall read the records indicated in the AFL using the READ RECORD command and process the response as defined in [EMV Book 3]. At this point, the Kernel needs to determine if all mandatory data elements are present. Even if the Kernel reads data objects that are not recognised by the Kernel (that is, their tags are unknown by the Kernel), the Kernel shall not terminate the transaction. Requirement – Presence of Mandatory Data Elements 3.4.1.2 If any of the following mandatory Data Elements is absent from the card:
- CDOL1 (Tag ‘8C’)
- Track2 Equivalent Data (Tag ‘57’)
- Application Expiration Date (Tag ‘5F24’)
- Application Primary Account Number (PAN) (Tag ‘5A’) Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10. If Offline Data Authentication is supported, CDA is the one and only mandatory Data Authentication Method3 supported by the Kernel in ‘EMV Mode’, hence the Kernel shall ensure that all the appropriate data elements are present. 3 SDA/DDA is not supported for EMV Mode. June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.4 Read Application Data 3.4.1.3 If the Transaction Mode is ‘EMV Mode’ And Offline Data Authentication is supported (implementation and acquirer option) And the AIP (Tag ‘82’) indicates that CDA is supported (Byte 1 bit 1 is ‘1’) And any of the following Data Elements is absent from the card:
- Certification Authority Public Key Index (Tag ‘8F’)
- Issuer Public Key Certificate (Tag ‘90’)
- Issuer Public Key Exponent (Tag ‘9F32’)
- Issuer Public Key Remainder (Tag ‘92’), when required (based on the sizes of tags ‘9F46’ and ‘90’, when both are present)
- ICC Public Key Certificate (Tag ‘9F46’)
- ICC Public Key Exponent (Tag ‘9F47’)
- ICC Public Key Remainder (Tag ‘9F48’), when required (based on the ICC Public Key Length and the size of tag ‘9F46’, when both are present) Then the Kernel shall set TVR Byte 1 bit 6 (‘ICC Data Missing’) and Byte 1 bit 3 (‘CDA Failed’) to ‘1’. (except for when Issuer Public Key Remainder (Tag ‘92’) and ICC Public Key Remainder (Tag ‘9F48’) are not required.)4 3.4.1.4 If the Transaction Mode is ‘EMV Mode’ And Offline Data Authentication is supported (implementation and acquirer option) And the Certification Authority Public Key corresponding to the CAPK index (Tag ‘8F’) provided by the card is not present in the Kernel configuration data, Then the Kernel shall set TVR Byte 1 bit 3 (‘CDA Failed’) to ‘1’. (Note: the kernel recovers the ICC public key later during the transaction to optimise the performance.) 4 If the kernel performs the validation of certificates during CDA Signature verification, it is not mandatory to check the absence of data elements and to set the TVR value described in the requirement 3.4.1.3 June 2023 EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.5 Terminal Risk Management 3.5 Terminal Risk Management Terminal Risk Management consists of verifications that compare the transaction amount with reader based limits, and take appropriate action if the limit is exceeded. The Acquirer's Exception List may also be checked. Terminal Risk Management is mandatory and always performed.
3.5.1 Contactless Limit Check Requirement – Contactless Limit Check 3.5.1.1 If the Transaction Mode is ‘Legacy Mode’ And the Contactless Transaction Limit is present And the value of Amount, Authorised (Numeric) (Tag ‘9F02’) is greater than or equal to this limit, Then the Kernel shall terminate the transaction and provide a Select Next Outcome as described in Section 3.12.10.
3.5.2 CVM Required Limit Check Requirement – CVM Required Limit Check 3.5.2.1 If the CVM Required Limit is present And the Transaction Type corresponds to a Purchase or CashAdvance transaction (i.e. value is ‘00’, ‘01’ or ‘09’) And the value of Amount, Authorised (Numeric) (Tag ‘9F02’) is greater than or equal to this limit, Then the Kernel shall indicate ‘CVM Required by Reader’ (Byte 1, bit 8) in the dynamic Terminal Interchange Profile (Tag ‘9F53’). June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3.5.3 Floor Limit Check 3 Kernel Processing 3.5 Terminal Risk Management Requirement – Floor Limit Check 3.5.3.1 If any of the conditions below is true:
- The Transaction Mode is ‘Legacy Mode’
- The Terminal Type (Tag ‘9F35’) indicates that the reader is online-only (value = ‘x1’ or ‘x4’)
- The Amount, Authorised is a single unit of currency5 and the Combination Options Byte 1 Bit 7 is set to 1b (‘Status Check Supported’) Then the Kernel shall set TVR Byte 4 bit 8 (‘Transaction exceeds Floor Limit’) to ‘1’.
3.5.3.2 If the Transaction Mode is ‘EMV Mode’ And the Contactless Floor Limit is present And the value of Amount, Authorised (Numeric) (Tag ‘9F02’) is greater than or equal to this limit, Then the Kernel shall set TVR Byte 4 bit 8 (‘Transaction exceeds Floor Limit’) to ‘1’.
3.5.4 Random Transaction Selection Requirement – Random Transaction Selection 3.5.4.1 If the Transaction Mode is ‘EMV Mode’ And the Combination Options indicate that ‘Random Transaction Selection supported’ And the TVR Byte 4 bit 8 has value ‘0’ (Floor Limit not exceeded), Then the Kernel shall perform Random Transaction Selection as described in [EMV Book 3]. 5 The Amount corresponding to a single unit of currency is obtained as 10Transaction Currency Exponent. E.g. for USD, where Transaction Currency Exponent = 2, a single unit of currency (1.00 USD) is coded as ‘000000000100’. The Transaction Currency Exponent is a Kernel configuration parameter. June 2023
EMV® Specifications for Payment Systems Kernel C-5 Specification v2.11 3 Kernel Processing 3.5 Terminal Risk Management Requirement – Random Transaction Selection 3.5.4.2 If the transaction is randomly selected for online authorisation, Then the Kernel shall set TVR Byte 4 bit 5 (‘Transaction selected randomly for online processing’) to ‘1’.
3.5.5 Exception File Check Exception file check is both an Implementation Option as well as an Acquirer Option. When applicable, the exact implementation of this check is left at the discretion of the implementer. It may, for instance, take advantage of the Data Exchange mechanism described in Book A. Requirement – Exception File Check 3.5.5.1 If all the conditions below are true:
- the Transaction Mode is ‘EMV Mode’
- Exception File Check is supported (Implementation Option)
- the Combination Options (Acquirer Options) indicate that ‘Exception File Check required’ Then the Kernel shall perform Exception File Check as described in [EMV Book 4].
3.5.5.2 If the card number (PAN) has been found in the Exception File, Then the Kernel shall set TVR Byte 1 bit 5 (‘Card appears on terminal exception file’) to ‘1’. June 2023
© 2011-2023 EMVCo, LLC. All right
Shown in part. Read the original for the full text.