Book C-7 Kernel Specification

© 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV ® Contactless Specifications for Payment Systems Book C-7 Kernel 7 Specification Version 2.12 June 2026 EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page i / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Legal Notice Unless the user has an applicable separate agreement with EMVCo or with the applicable payment system, any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com and the following supplemental terms and conditions. The license granted in the EMVCo Terms of Use specifically excludes (a) the right to disclose, distribute or publicly display these Specifications or otherwise make these Specifications available to any third party, and (b) the right to make, use, sell, offer for sale, or import any software or hardware that practices, in whole or in part, these Specifications. Further, EMVCo does not grant any right to use the Kernel Specifications to develop contactless payment applications designed for use on a Card (or components of such applications). As used in these supplemental terms and conditions, the term “Card” means a proximity integrated circuit card or other device containing an integrated circuit chip designed to facilitate contactless payment transactions. Additionally, a Card may include a contact interface and/or magnetic stripe used to facilitate payment transactions. To use the Specifications to develop contactless payment applications designed for use on a Card (or components of such applications), please contact the applicable payment system. To use the Specifications to develop or manufacture products, or in any other manner not provided in the EMVCo Terms of Use, please contact EMVCo. These 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 NON - INFRINGEMENT, 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 these 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 these 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 responsible 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 these Specifications. EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page ii / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Revision Log – Version 2.12 The following changes have been made to the document since the publication of Version 2.11. Incorporated changes described in the following Specification Updates:  Add the descriptions of Book C-8 and Book E in Section 1.3.  Update Figure 2-1 with adding Kernel 8 in Entry point. Other editorial changes:  Editorial changes in Annex A. EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page iii / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Contents 1 General ............................................................................................................... 1 1.1 Scope ......................................................................................................... 1 1.2 Audience .................................................................................................... 1 1.3 Volumes of the Contactless Specifications ................................................. 1 1.4 Reference Materials ................................................................................... 2 1.5 Overview .................................................................................................... 2 2 POS System ....................................................................................................... 3 3 Processing Overview ........................................................................................ 5 3.1 General Description .................................................................................... 5 3.2 Overview of Transaction Processing .......................................................... 6 3.2.1 Kernel Activation ............................................................................. 6 3.2.2 Application Initialization ................................................................... 6 3.2.3 Read Application Data .................................................................... 8 3.2.4 Offline Data Authentication ............................................................. 9 3.2.5 Online Processing ........................................................................... 9 3.2.6 Transaction Completion ................................................................ 10 3.3 General Transaction Flow ......................................................................... 11 4 Transaction Processing .................................................................................. 13 4.1 Application Initialization ............................................................................ 13 4.1.1 Input.............................................................................................. 13 4.1.2 Commands ................................................................................... 13 4.1.3 Flow Chart .................................................................................... 15 4.1.4 Kernel Processing ......................................................................... 15 4.2 Read Application Data .............................................................................. 25 4.2.1 Input.............................................................................................. 26 4.2.2 Commands ................................................................................... 26 4.2.3 Flow Chart .................................................................................... 27 4.2.4 Kernel Processing ......................................................................... 28 4.3 Offline Data Authentication ....................................................................... 30 4.3.1 Input.............................................................................................. 31 4.3.2 Kernel Processing ......................................................................... 32 4.4 Cardholder Verification ............................................................................. 37 4.4.1 General Requirements .................................................................. 37 4.4.2 CVM Processing ........................................................................... 38 4.5 Outcome ................................................................................................... 40 4.5.1 Approved ...................................................................................... 40 EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page iv / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 4.5.2 Online Request ............................................................................. 41 4.5.3 Try again (1) ................................................................................. 43 4.5.4 Declined ........................................................................................ 44 4.5.5 Try Another Interface .................................................................... 44 4.5.6 Select Next ................................................................................... 45 4.5.7 End Application ............................................................................. 46 4.5.8 Try again (2) ................................................................................. 47 Annex A Data Dictionary............................................................................ 49 Annex B Fast Dynamic Data Authentication (fDDA) ................................ 56 Annex C Data Elements ............................................................................. 58 Annex D Transaction Log Retrieval .......................................................... 61 Annex E Glossary ...................................................................................... 62 EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page v / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Figures Figure 2-1 Logical Architecture ................................................................................. 4 Figure 3-1 Sample of EMV Mode Transaction Flow ................................................ 12 Figure 4-1 GPO Processing .................................................................................... 15 Figure 4-2 Read Application Data ........................................................................... 27 Figure B-1 Sample of Data Exchange Related to fDDA ........................................... 57 EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page vi / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Tables Table 3-1 Terminal Transaction Qualifiers ................................................................. 7 Table 4-1 Response of SELECT AID ...................................................................... 13 Table 4-2 GPO Command Message ....................................................................... 14 Table 4-3 GPO Response Data if The Card’s Transaction Disposition is an ARQC （without Offline Data Authentication） or AAC ................................................... 21 Table 4-4 GPO Response Data if The Card’s Transaction Disposition is a TC ........ 22 Table 4-5 GPO Response Data if The Card’s Transaction Disposition is an ARQC with Offline Data Authentication ................................................................... 24 Table 4-6 Card Data used in Read Application Data ............................................... 26 Table 4-7 Offline Data Authentication--Terminal Data ............................................. 31 Table 4-8 Offline Data Authentication--Card Data ................................................... 31 Table 4-9 Dynamic Kernel Data to be Hashed ........................................................ 34 Table 4-10 IC Card Dynamic Data to be Hashed .................................................... 35 Table A-1 Data Dictionary ....................................................................................... 50 Table C-1 Clearing Data Element............................................................................ 58 EMV ® Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page vii / vii © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirements Requirement – Online Authorization ........................................................................ 10 Requirement – PDOL Check ................................................................................... 16 Requirement – TTQ Resetting ................................................................................ 16 Requirement – Processing of Status Code .............................................................. 16 Requirement –Transaction Disposition .................................................................... 18 Requirement – Mandatory-Data Check ................................................................... 19 Requirement – L1 Errors in Reading Application Data ............................................ 28 Requirement – Processing of READ RECORD Response ...................................... 28 Requirement – Exception File ................................................................................. 30 Requirement – Other Exception Handlings ............................................................. 30 Requirement – fDDA Version Check ....................................................................... 33 Requirement – fDDA Data Check............................................................................ 34 Requirement – fDDA Verification ............................................................................ 35 Requirement – fDDA Failed or Not Performed ........................................................ 36 Requirement – CVM Check..................................................................................... 38 Requirement – CVM Check..................................................................................... 39 Requirement – APPROVED Outcome .................................................................... 40 Requirement – ONLINE REQUEST Outcome ......................................................... 42 Requirement – TRY AGAIN Outcome ..................................................................... 43 Requirement – DECLINED Outcome ...................................................................... 44 Requirement – TRY ANOTHER INTERFACE Outcome .......................................... 45 Requirement – SELECT NEXT Outcome ................................................................ 46 Requirement – END APPLICATION Outcome ........................................................ 47 Requirement – TRY AGAIN Outcome ..................................................................... 48 EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 1 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 1 General 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 7 Specification, describes one of several kernels defined for use with Entry Point. 1.2 Audience This specification is intended to be used by system designers in payment systems and financial institution staff responsible for implementing financial applications. 1.3 Volumes of the Contactless Specifications This specification is part of a eleven-volume set: Book A: Architecture and General Requirements Book B: Entry Point Specification Book C-2: Kernel 2 Specification Book C-3: Kernel 3 Specification Book C-4: Kernel 4 Specification Book C-5: Kernel 5 Specification Book C-6: Kernel 6 Specification Book C-7: Kernel 7 Specification Book C-8: Kernel 8 Specification Book E: Security and Key Management Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 2 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 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 4.3] EMV Integrated Circuit Card Specifications for Payment Systems, Version 4.3, November 2011, including: [EMV 4.3 Book 1] EMV Integrated Circuit Card Specifications for Payment Systems, Book 1, Application Independent ICC to Terminal Interface Requirements [EMV 4.3 Book 2] EMV Integrated Circuit Card Specifications for Payment Systems, Book 2, Security and Key Management [EMV 4.3 Book 3] EMV Integrated Circuit Card Specifications for Payment Systems, Book 3, Application Specification [EMV 4.3 Book 4] 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 reader to understand the structure of this specification so that they could read it effectively. Chapter 2 introduces the main architecture of the POS System supported by Kernel7. Chapter 3 gives an overview of the features of Kernel 7 and its configuration and main functions. Chapter 4 breaks down the main transaction steps, within each details are provided to describe the necessary data to be processed, commands used and Kernel processing as well. Annex A contains the dictionary of data objects used by Kernel 7, including the kernel data elements and card elements must be supported by Kernel 7 as well. Annex B is a sample of Fast Dynamic Data Authentications and provides relevant explanations. Annex C lists authorization and clearing data needed to be provided by Kernel 7 when the Kernel sends an ONLINE REQUEST or APPROVE as an output to Entry Point. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 3 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Annex D describes the process of retrieving card transaction log. Annex E is a glossary of terms and abbreviations in this specification. 2 POS System This chapter lists the possible physical architectures of POS system conducting EMV Mode contactless transactions; transactions using contact interface or magstripe are out of the scope of this specification. POS System shall be able to host the following functions in Kernel7: ⚫ Interact with contactless card ⚫ Process application selection, complete kernel activation and transfer transaction outcomes ⚫ Display transaction information to cardholders ⚫ Display transaction information to merchants ⚫ User Interface to input transaction amount ⚫ Cardholder verification ⚫ Online capabilities ⚫ Store transaction data used for offline transaction clearing In terms of hardware designing, it could be divided into the following 3 categories: 1． Programmable Contactless Readers (PCRs) A PCR is a smart reader which is able to conduct all or partial kernel functions including providing the contactless interface with the card and processing the transaction data. A PCR is a programmable device to achieve alternative functions. 2． Combination of Terminal and Non-programmable Contactless Readers (Non-PCRs) All the features in a Non-PCR are hardcoded and cannot be re-programmed once released. A Non-PCR is a separate entity connected with a terminal and it execute instructions from the terminal to interact with card, control visual indicators, audio indication and LCD display, and transfer outcomes as well. Kernel functions are performed in the terminal. 3． Fully Integrated Terminal Modules including contactless reading module are integrated in one device. The design described in this document is based on a physical architecture that is along the lines of Fully Integrated Terminal; however it is not intended to be prescriptive. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 4 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. The logical partitioning of the Fully Integrated Terminal is illustrated Figure 2-1.Figure 2-1 Logical Architecture The three main components in the above figure are frequently used in this specification and each of them is responsible for specific functions as described below: Terminal – within this specification, the Terminal is a term embraces a range of devices that provide the interaction for card acceptance at physical locations. The Terminal hosts the user interface for card holder and merchant, Payment System network connectivity and peripheral devices such as PIN pads and receipt printers. Entry Point – see Book A and Book B. Kernel – the Kernel within this specification refers to the Kernel 7 unless the word is followed by a specific number. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 5 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 3 Processing Overview 3.1 General Description Entry Point activates Kernel7 once completing Application Selection and passes the control to the Kernel. The subsequent processing will be completed jointly by the Kernel and Card. When the control transferred from Entry Point to the Kernel, Entry Point shall provide transaction data, relevant configuration parameters and FCI information returned in Application Selection. The EMV Mode supported by Kernel 7 is an optimization of EMV full transaction processing and command sequences to guarantee the time that the cardholder holds the payment card close to the terminal be as minimal as possible. Meanwhile, it supports the same data authentication working in EMV full procedures, which allows for a quick transaction with a required security level. Kernel 7 possesses the following characteristics compared with EMV full processing: 1) Kernel 7 supports Online PIN, signature and CDCVM as cardholder verification methods; 2) If Offline Data Authentication is performed, it is performed by the Kernel and there’s no requirement of card’s presences in the communication field. Once the Kernel completes its processing, it shall output the transaction Outcome to Entry Point. Meanwhile the control will be transferred from the Kernel to Entry Point for further handling, which starts from initiating an appropriate Start point based on the Outcome and parameters in the Outcome. (Start point refers to different stages of Entry Point in EMV contactless specification, including Start A, Start B, Start C and Start D. Refer to Book A: Architecture and General Requirements for details). Kernel 7 includes the following steps: ⚫ Kernel Activation (Mandatory) ⚫ Application Initiation (Mandatory) ⚫ Read Application Data (Conditional, if the transaction is authorised offline) ⚫ Offline Data Authentication (Mandatory if the transaction is authorized offline. Optional if the transaction is authorized online) ⚫ Online Processing (Conditional, if the transaction is authorized online) ⚫ Transaction completion (Mandatory) Kernel 7 should support Payment Account Reference ("9F24") without disruption to the terminal processing. Kernel 7 should be capable of reading PAR data. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 6 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 3.2 Overview of Transaction Processing 3.2.1 Kernel Activation Entry Point activates the Kernel once completing application selection, transfers transaction processing control to the Kernel and provides card information as well as transaction information to the Kernel for further use. On Kernel activation, the interaction between the Kernel and the card has been established and the connection will be maintained until the Kernel returns an Outcome to Entry Point. Entry Point’s output to the Kernel includes the pre-processing results, the picked combination profile, transaction data and configuration parameters. All these information passed to the Kernel are crucial input for Transaction processing. These data include the following elements: ⚫ Transaction Amount; ⚫ Terminal Transaction Qualifiers (TTQ) (Pre-configured in the Terminal which will be reset in Entry Point pre-processing); ⚫ Terminal Unpredictable Number; ⚫ Copy of TTQ (Reset in Entry Point pre-processing); ⚫ FCI of the selected application in pre-processing; 3.2.2 Application Initialization Once the Kernel receives the copy of TTQ from Entry Point, it shall do the following process: 3) Special readers such as transit acceptance terminals that support Offline Data Authentication for online authorisation, check the presence and Byte 1 bit 7 of DF61 in Select AID response: If DF61 is not returned or Byte 1 bit 7 of the returned DF61 is "0", reset the copy of TTQ Byte 1 bit 7 to "1" and continue with non-EMV processing. This is out of scope of this specification. For further information, please refer to your payment system for implementation guide. Else (Byte 1 bit 7 of the returned DF61 is "1"), reset the copy of TTQ Byte 1 bit 7 to "0", reset the copy of TTQ Byte 1 bit 1 to "1", reset the copy of TTQ Byte 1 bit 6 to "1", reset the copy of TTQ Byte 2 bit 8 to "1". 4) Reset the copy of TTQ Byte 3 bit1 - 6 and bit 8 to “0”; 5) Reset the copy of TTQ Byte 4 bit 8 to "1". See Table 3-1 for the definition of TTQ supported by this specification. If not specified, the TTQ in subsequent context refer to TTQ reset in this step. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 7 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. The Kernel informs the card of the start of transaction by issuing GET PROCESSING OPTIONS (GPO) command, and includes any data that the card requests in PDOL during pre- processing. The card provides transaction disposition in GPO response. If the card requests the transaction to be authorized offline, the card shall generate dynamic signature data and Fast Dynamic Data Authentication (fDDA) shall be performed to complete the transaction.. If the returned Application Cryptogram is Offline Authorization, the Kernel shall read card data according to Application File Locator (AFL) returned during application initialization. Details of Read Record can be found in section 3.2.3. Multiple Read Record message exchanges may happen until the last record is transferred before the card leaves the field. If Application Cryptogram is Online Authorization, the Kernel may or may not perform Offline Data Authentication. If the kernel performs Offline Data Authentication, it will read application data. Details of Online Processing can be found in section 3.2.5. Card may leave the field once returning GPO response. Table 3-1 Terminal Transaction Qualifiers Byte Bit Definition 1 8 RFU 1 7 1 – Full transaction flow in Contactless interface Support 0 – Full transaction flow in Contactless interface Not Support 6 1 – EMV Mode Supported 0 – EMV Mode Not supported 5 1 – Full transaction flow in contact interface Support 0 –Full transaction flow in contact interface Not Support 4 1 – Offline-only terminal 0 – Online-capable terminal 3 1 – Online PIN Supported 0 – Online PIN Not Supported 2 1 – Signature Supported 0 – Signature Not Supported 1 All RFU bits and bytes shall be set to zero unless explicitly specified otherwise. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 8 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Byte Bit Definition 1 1 – Offline Data Authentication for Online Authorisation Supported 0 – Offline Data Authentication for Online Authorisation Not Supported 2 8 1 – Request Online cryptogram 0 – No Online cryptogram 7 1 –CVM Requested 0 – No CVM Requested 6-1 RFU 3 8 RFU 7 1- Consumer Device CVM Supported 0- Consumer Device CVM Not Supported 6-1 RFU 4 8 1 –fDDA v1.0 Supported 7-1 RFU 3.2.3 Read Application Data Read Application Data Request shall be performed in offline transactions and may be performed in online transactions. Read Application Data step is followed with Offline Data Authentication. If the card requests offline authorization, it shall return AFL in the GPO response. The Kernel uses READ RECORD command to retrieve the card data according to Short File Identifier (SFI) and record number in AFL. The Electronic Cash (EC) balance will not be updated in a persistent memory until the last record is read by the Kernel. Once the last record is sent to the Kernel, the card may leave the field and the Kernel performs Offline Data Authentication. Details of Offline Data Authentication can be found in section 3.2.4. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 9 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 3.2.4 Offline Data Authentication Offline Data Authentication shall be supported by Offline-capable terminals and can be performed in both online and offline transaction. fDDA is used to verify the dynamic signature and authenticate the data from the card. fDDA is the Dynamic Data Authentication(DDA) specifically used in contactless interface which not only to guarantee that the card data has not been broken or manipulated since issued, but also to confirm the legitimacy of critical ICC- resident/generated data and data received by the terminal. fDDA precludes the counterfeiting of any such fake card. In order to perform fDDA in offline transaction, the Kernel shall be capable to quickly shield SDA support function when necessary. Once SDA is shielded, transactions could not be approved offline unless the card supports fDDA. Special readers such as transit acceptance terminals support Offline Data Authentication for online authorisation. Offline Data Authentication feature is an implementation option. Please refer to your payment system for implementation guide including additional processing upon failure of Offline Data Authentication. fDDA is different from standard DDA used in full flow 2 for the following aspects: ⚫ Instead of using INTERNAL AUTHENTICATE Command , the card generates Dynamic signature on receiving GPO command. DDOL is not supported by Kernel7. ⚫ The result of fDDA verification is not stored in Terminal Verification Results (TVR) or sent to Issuer in online message. There are two versions of fDDA including version00 and version01 and an offline-capable Kernel shall only support version 01. All the fDDA in this specification refer to version01 by default unless explicitly specified otherwise. 3.2.5 Online Processing If the card’s transaction disposition indicates an Online Authorization in the GPO response, the Kernel sends an Online Request Outcome with parameters set appropriately and clearing data as well (see 4.5.2). Online–capable terminal perform online processing once Entry Point receives the outcome and alter the transaction disposition to Declined Outcome with parameters if it failed to go online.(see 4.5.4) 2 Full flow refers to the EMV contact flow. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 10 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Online Authorization The Kernel shall apply the following principles when performing online authorization: If TTQ Byte 1 bit 4 is "0", meaning the terminal is an Online-capable terminal, then the Kernel shall provide an Online Request Outcome, and transfers the clearing data to Entry Point (see 4.5.2 for parameter configuration) to perform an online transaction. Else the Kernel declines the transaction with a Declined Outcome (see 4.5.4). The terminal sends an authorisation request to the issuer host. Online Processing allows the issuer host to review to approve or decline transactions using the issuer’s host based risk management parameters. (Risk management in issuer host is out of this specification.) If the issuer approves the transaction, the account will be updated in the host whilst the EC balance on the card remains unchanged. On receiving the decision from the issuer, the terminal displays the transaction disposition to the cardholder. The transaction is considered as completed and the Kernel will no longer be re-activated until next transaction. 3.2.6 Transaction Completion From Kernel's perspective, an Outcome provided to Entry Point is considered as the last step indicating the transaction is completed. The outcomes may be one of the followings: ⚫ Approved ⚫ Online Request ⚫ Try Again ⚫ Declined ⚫ Try Another Interface ⚫ Select Next ⚫ End Application See 4.5 for details. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 11 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 3.3 General Transaction Flow Figure 3-1 illustrates a sample of a complete transaction in EMV Mode. Before handing over the control to the Kernel, Entry Point finishes the pre-processing (Start A), followed with establishing contactless communication connection (Start B), then selects combination (Start C) and ends with activating Kernel (Start D). The Kernel handles the interaction with the card until the transaction disposition has been provided to Entry Point, attached with the necessary parameters and clearing data if any. Entry Point takes over the outcomes with the parameters and proceed with the rest of the procedure including Online processing, CVM and transaction disposition display without re- starting the Kernel. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 12 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Application initialization Transaction declined Online request Kernel processing Performing the sequence of StartA,StartB,StartC and StartD EntryPonit EntryPoint Read application data fDDA verification Start A Start CStart B Start D Transaction approved fDDA verification succeeded AAC Yes Other situations Normal flow Exceptional flow Procedures required if requested Read application data fDDA verification TC ARQC No Figure 3-1 Sample of EMV Mode Transaction Flow EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 13 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 4 Transaction Processing 4.1 Application Initialization 4.1.1 Input The input of Application Initialization includes the data passed from Entry Point which is the result of pre-processing, the data can be found in 3.2.1. Table 4-1 illustrates response of SELECT AID command which includes the FCI template of the selected application: Table 4-1 Response of SELECT AID Tag Value Existence ‘6F’ FCI Module M ‘84’ DF name M ‘A5’ Special module for FCI data M ‘9F38’ PDOL M ‘50’ Application tag O ‘87’ Application priority indicator O ‘5F2D’ Preferred language O ‘9F11’ Issuer Code Table Index O ‘9F12’ Application Priority Name O ‘BF0C’ Issuer Discretionary data (FCI) O ‘xxxx’ One or more additional (special) data elements from application provider, issuer or IC card provider O 4.1.2 Commands The Kernel uses GPO command in Application Initialization. The format of GPO command conforms to [EMV 4.3 Book 3]. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 14 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Definition and Scope The GET PROCESSING OPTIONS command initiates the transaction within the ICC. Command Message Table 4-2 GPO Command Message Code Value CLA “80” INS “A8” P1 “00”; all other values are RFU P2 “00”; all other values are RFU Lc var. Data Processing Options Data Object List (PDOL) related data Le “00” Data Field Sent in the Command Message The data field of the command message contains all the Kernel data requested in the PDOL returned during pre-processing in Entry Point. Data Field Returned in the Response Message The coding of the data object shall be according to Format 2 described in [EMV 4.3 Book3] see 6.5.8.4. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 15 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 4.1.3 Flow Chart GPO Processing PDOL exists “9F66” exists in PDOL TTQ resetting Card responds to GPO SW1 SW2 =‘9000’, and format correct? Issuer Application Data (“9F10”) exists in GPO Response Application Cryptogram Mandatory-data check (AIP, ATC, Track 2 equivalent data, Application Cryptogram) Mandatory-data check (AIP, ATC, AFL, Application Cryptogram) Yes Yes Yes Yes Yes TC ARQC、AAC Terminate transaction No No Try AgainNo No Subsequent processings Send GPO command Data element missing N Yes Return application selection No SW1SW2=‘6986’ No Try Again Yes Figure 4-1 GPO Processing 4.1.4 Kernel Processing EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 16 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – PDOL Check 4.1.4.1 The Kernel shall check the existence of PDOL and Terminal Transaction Qualifiers (Tag "9F66"): If PDOL doesn't exist in the FCI of the selected application which is passed over from Entry Point, Then the Kernel shall terminate the processing and select next application in the candidate list by providing a Select Next Outcome, see 4.5.6. Else continue to check the existence of Terminal Transaction Qualifiers (Tag ‘9F66’) in PDOL. If exists, Then the Kernel continues with TTQ resetting, see 4.1.4.2. Else the Kernel shall terminate the processing and select next application in the candidate list by providing a Select Next Outcome, see 4.5.6. Requirement – TTQ Resetting 4.1.4.2 The Kernel shall reset the copy of TTQ passed from Entry Point on Kernel Activation : Set the copy of TTQ Byte 4 bit 8 to "1". Requirement – Processing of Status Code 4.1.4.3 The Kernel shall check SW1 SW2 in GPO response: If any L1 error 3 occurs, Then the Kernel shall terminate the processing by providing a Try Again Outcome, which will remind the cardholder to represent the card, see 4.5.3. If SW1 SW2 does NOT equal to "9000", If SW1 SW2 equals to “6986” 3 L1 errors can be one of the following: timeout, protocol error or transmission error. See [Level 1 Specifications for Payment Systems, EMV Contactless Interface Specification] for details. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 17 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Processing of Status Code Then the Kernel shall terminate the processing by providing a Try Again Outcome, which will remind the cardholder to represent the card, see 4.5.8. Else If TTQ Bit 5 Byte 1 is "1", indicating Contact interface is supported, or Magstripe is supported in the terminal, Then the Kernel shall terminate the processing by providing a Try Another Interface Outcome, which will remind the cardholder to conduct the transaction in another interface. The Kernel sets the Parameters as a result of the following check: If the terminal supports contact interface, Then the Kernel sets Alternate Interface Preference to Contact Chip. Else the Kernel sets Alternate Interface Preference to Mag-stripe. Else the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. If SW1 SW2 equals to "9000", Then the Kernel checks the data format of GPO response. Only Format 2 of GPO response is supported, see [EMV 4.3 Book3] see 6.5.8.4. If there is any format error, Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7 Else the Kernel continues with The Card’s Transaction Disposition, see 4.1.4.4. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 18 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement –Transaction Disposition 4.1.4.4 The Card’s transaction disposition is included in the Cryptogram Information Data (Tag “9F27”). If the card does not return CID, the Kernel shall: - Initialise CID to ‘00’ - Set CID bits 8-7 to the value of Issuer Application Data (Tag “9F10”) Byte 5 bit 6-5 If the card returns an ARQC (CID bit8-7 = ‘10’), indicting an online transaction is requested. Then the Kernel continues with mandatory-data check for online request, see 4.1.4.5. If the card returns an AAC (CID bit8-7=’00’), indicting an offline decline. Then the Kernel continues with mandatory-data check for offline decline, see 4.1.4.5. If the card returns a TC (CID bit8-7=’01’), indicting an offline approval. Then the Kernel continues with mandatory-data check for offline approval, see 4.1.4.6. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 19 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Mandatory-Data Check 4.1.4.5 Table 4-3 illustrate the data returned in GPO response if the card’s transaction disposition is an ARQC without Offline Data Authentication or AAC, Table 4-5 illustrates the data returned in GPO reponse if the card's transaction disposition is an ARQC with Offline Data Authentication. Under these situations, the Kernel shall perform the followings: If the card’s disposition is ARQC (with or without Offline Data Authentication), Then If any Mandatory data listed in Table 4-3 and Table 4-5 is absent in the GPO response, Then the Kernel shall terminate the Kernel processing by providing an End Application Outcome, see 4.5.7. Else If AFL is returned (ARQC with Offline Data Authentication), Then the Kernel continues with AFL format check, see 4.1.4.7. The Kernel perform the Online Processing, see 3.2.5 . If the card’s disposition is AAC. If any Mandatory data listed in Table 4-3 is absent, Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. Else the Kernel declines the transaction by providing a Declined Outcome, see 4.5.4 EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 20 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Mandatory-Data Check 4.1.4.6 Table 4-4 illustrate the data returned in GPO response if the card’s transaction disposition is a TC, the Kernel shall perform the followings: If the card’s transaction disposition is TC, If any Mandatory data elements listed in Table 4-4 is absent, Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. Else the Kernel continues with AFL format check, see 4.1.4.7. 4.1.4.7 Table 4-6 illustrates the definition and format of AFL. The Kernel shall perform the followings: If No Entry exists in AFL, OR any one or more of the following format errors occurs:  An SFI of 0 or 31;  A starting record number of 0;  An ending record number less than the starting record number (byte 3 < byte 2).  Number of records participating in offline data authentication greater than the number of records (byte 4 > byte 3 - byte 2 + 1). Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. Else the Kernel continues with Read Application Data, see 4.2. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 21 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Table 4-3 GPO Response Data if The Card’s Transaction Disposition is an ARQC （without Offline Data Authentication） or AAC Tag Mandatory (M) Optional (O) Conditional (C) Data Element Name “82” M AIP “9F36” M ATC “57” M Track 2 Equivalent Data “9F10” M Issuer Application Data. “9F26” M Application Cryptogram “9F27” M Cryptogram Information Data “9F63” C If exists in card Product Identification Information This data can either be retrieved in GPO or READ RECORD “5F34” C If exists in card Application PAN Sequence Number “9F6C” C If exists in card Card Transaction Qualifiers “9F5D” C If the Available Offline Amount display is allowed Available Offline Spending Amount. Only if the Available Offline Spending Amount("9F5D") is personalized to 1, the card returns this data in GPO response or can be retrieved by READ RECORD. Meanwhile, the Card Additional Processing (Byte 1 bit 1) shall be personalised to 1 to indicate that this amount will be calculated and included in all contactless transactions. Personalization of Available Offline Spending Amount to 1 also means that this data can be retrieved by GET DATA command. "9F24" C If exists in card Payment Account Reference EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 22 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Tag Mandatory (M) Optional (O) Conditional (C) Data Element Name “5F20” or “9F0B” O Cardholder Name If the length of Cardholder Name is less than or equal to 26 bytes, "5F20" will be returned; if the length of Cardholder Name is more than 26 bytes, "9F0B" will be returned. This data can either be retrieved in GPO or READ RECORD “9F7C” O Partner Proprietary Data This data can either be retrieved in GPO or READ RECORD “9F25” C If using Token instead of PAN The last 4 numbers of PAN “9F19” C If using Token instead of PAN Token requestor identifier Table 4-4 GPO Response Data if The Card’s Transaction Disposition is a TC Tag Mandatory (M) Conditional (C) Data element name “82” M AIP “94” M AFL “9F36” M ATC “9F26” M Application Cryptogram “9F10” M Issuer application data “9F27” M Cryptogram Information Data EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 23 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Tag Mandatory (M) Conditional (C) Data element name “57” C If Track 2 Equivalent Data is not part of Signed Static Application Data. Track 2 Equivalent Data “5F34” C If exists in card Application PAN Sequence Number. “9F4B” C If fDDA is supported. Signed Dynamic Application Data This data can either be retrieved in GPO or READ RECORD “9F6C” C If exists in card Card Transaction Qualifiers “9F5D” C If the Available Offline Amount display is allowed. Available Offline Spending Amount. Only if the Available Offline Spending Amount("9F5D") is personalized to 1, the card returns this data in GPO response or can be retrieved by READ RECORD. Meanwhile, the Card Additional Processing (Byte 1 bit 1) shall be personalised to 1 to indicate that this amount will be calculated and included in all contactless transactions. Personalization of Available Offline Spending Amount to 1 also means that this data can be retrieved by GET DATA command. "9F24" C If exists in card Payment Account Reference “9F7C” O Partner Proprietary Data This data can either be retrieved in GPO or READ RECORD “9F25” C If using Token instead of PAN Last 4 Digits of PAN “9F19” C If using Token instead of PAN Token Requestor ID EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 24 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Table 4-5 GPO Response Data if The Card’s Transaction Disposition is an ARQC with Offline Data Authentication Tag Mandatory (M) Optional (O) Conditional (C) Data Element Name “82” M AIP “94” M AFL “9F36” M ATC “57” C If Track 2 Equivalent Data is not part of Signed Static Application Data. Track 2 Equivalent Data “9F10” M Issuer Application Data. “9F26” M Application Cryptogram “9F27” M Cryptogram Information Data “9F4B” C If fDDA is supported. Signed Dynamic Application Data This data can either be retrieved in GPO or READ RECORD “9F63” C If exists in card Product Identification Information This data can either be retrieved in GPO or READ RECORD “5F34” C If exists in card Application PAN Sequence Number “9F6C” C If exists in card Card Transaction Qualifiers EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 25 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Tag Mandatory (M) Optional (O) Conditional (C) Data Element Name “9F5D” C If the Available Offline Amount display is allowed Available Offline Spending Amount. Only if the Available Offline Spending Amount("9F5D") is personalized to 1, the card returns this data in GPO response or can be retrieved by READ RECORD. Meanwhile, the Card Additional Processing (Byte 1 bit 1) shall be personalised to 1 to indicate that this amount will be calculated and included in all contactless transactions. Personalization of Available Offline Spending Amount to 1 also means that this data can be retrieved by GET DATA command. "9F24" C If exists in card Payment Account Reference “5F20” or “9F0B” O Cardholder Name If the length of Cardholder Name is less than or equal to 26 bytes, "5F20" will be returned; if the length of Cardholder Name is more than 26 bytes, "9F0B" will be returned. This data can either be retrieved in GPO or READ RECORD “9F7C” O Partner Proprietary Data This data can either be retrieved in GPO or READ RECORD “9F25” C If using Token instead of PAN The last 4 numbers of PAN “9F19” C If using Token instead of PAN Token requestor identifier 4.2 Read Application Data Read Application Data can be performed in both online and offline transactions. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 26 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. According to AFL in the GPO response, the Kernel reads the data contained in the card to proceed fDDA verification and various functions including checking the Application Expiration date and Exception File if any. 4.2.1 Input Table 4-6 lists the data returned from the card in Application Initialization which will be used in Read Application Data. Table 4-6 Card Data used in Read Application Data Data Object Description Application File Locator (AFL) Indicates the file location and range of records which contain card data to be read by the Kernel. For each file to be read, the AFL contains the following information:  Byte 1 - Short File Identifier (a numeric file label)  Byte 2 - Record number of the first record to be read  Byte 3 - Record number of the last record to be read  Byte 4 - Number of consecutive records containing data to be used in Offline Data Authentication beginning with the first record to be read as indicated in Byte 2. 4.2.2 Commands The Kernel uses READ RECORD command in Read Application Data. The format of READ RECORD command conforms to [EMV 4.3 Book 3]. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 27 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 4.2.3 Flow Chart Read Applica tion data L1 error Data format error occurs Duplicated Tags returned No No Terminate transaction Yes Yes No GPO processing Read record No It is the last record Save to Tearing Transaction Log, and remind cardholder to represent the card SW1 SW2=‘9000’? Yes Yes Same tag With the one returned In GPO Response Yes It is the last record No Yes Exception File Processing No Offline Data Authent ication Yes No Mandatory process Optional process Figure 4-2 Read Application Data EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 28 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. 4.2.4 Kernel Processing Each file entry in AFL contains the information of consecutive records in the AEF. For each record, the Kernel shall send a READ RECORD command until the last record is retrieved. If there is more than one file entry in AFL, the Kernel repeats the steps until all the entries have been process. Requirement – L1 Errors in Reading Application Data 4.2.4.1 In case of L1 errors, the Kernel shall perform the followings: If any L1 error occurs, THEN the Kernel shall terminate the processing by providing a Try Again Outcome, which will remind the cardholder to represent the card, see 4.5.3. Else the Kernel continues with Response Processing, see 4.2.4.2. Requirement – Processing of READ RECORD Response 4.2.4.2 The Kernel shall process the READ RECORD Response: If SW1 SW2 does NOT equal to ‘9000’, Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. Else the Kernel performs Data Format check , see 4.2.4.3. 4.2.4.3 The Kernel shall check the data in READ RECORD response. If any format error occurs in the response, Then the Kernel shall terminate the processing by providing an End Application Outcome, see 4.5.7. Else the Kernel checks the data duplication, see 4.2.4.4. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 29 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Processing of READ RECORD Response 4.2.4.4 The Kernel shall check the data duplication 4 in response. Data Duplication could happen between one data object returned in Read Application Data and another returned in Application Initialization, or between two data objects returned in Read Application Data. If data duplication occurs, Then the Kernel shall terminate the processing by providing an End Application Outcome , see 4.5.7. Else the Kernel continue with checking the application expiration date, see 4.2.4.5. 4.2.4.5 Once the Kernel retrieves the Application Expiration Date (“5F24”), it shall perform the followings: If the current date obtained from the terminal is greater than the Application Expiration Date (“5F24”), meaning the application is expired. The Kernel shall do the following process: If Card Transaction Qualifiers(“9F6C”), Byte 1 bit 4 value is “1”, meaning Go Online if Application Expires, Then the Kernel performs the Online Process, see 3.2.5, and display "The application is expired, transaction is going online" on screen. Else the Kernel shall decline the transaction by providing a Declined Outcome, see 4.5.4, and display "The application is expired, transaction declined" on screen. Else the Kernel perform the next step, see 4.2.4.6 4.2.4.6 The Kernel shall see whether the current record is the last one to be read. If the current record is the last record, If exception file exists in the terminal, Then the Kernel performs exception file check, see 4.2.4.7.. Else the Kernel continues with Offline Data Authentication, see 4.3. Else the Kernel reads the next record. 4 The data objects with the same Tag value are considered as a duplication. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 30 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – Exception File 4.2.4.7 This is an optional feature which is done only if the exception file exists in the terminal. If the leftmost digits of PAN Number exists in the exception file 5 , Then the Kernel declines transaction by providing a Declined Outcome, see 4.5.4. Requirement – Other Exception Handlings 4.2.4.8 If there exists any data object that in correct TLV format but undefined in this specification, Then the Kernel shall store them in memory for further use instead of terminating the transaction. 4.2.4.9 If any one or more of the followings occurs, the Kernel shall store the value and continue the transaction instead of terminating the transaction: ⚫ The length of Cardholder Name (“5F20”) is not consistent with the requirements specified in [EMV 4.3 Book3] Table A1. ⚫ The length of Cardholder Name Extension (“9F0B”) is not consistent with the requirements specified in [EMV 4.3 Book3] Table A1. ⚫ Both Cardholder Name (“5F20”) and Cardholder Name Extension (“9F0B”) are returned. 4.3 Offline Data Authentication The crucial requirement of a transaction over the contactless interface is the time that the cardholder has to hold the card in the field. Dynamic Data Authentication used in payment over the contactless interface is called fast Dynamic Data Authentication (fDDA) which can be performed without the card’s presence in the field. This enables the cardholder to remove the card just after Read Application Data and guarantee the security of ICC transaction, 5 There is no requirement in this specification for an exception file. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 31 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Only fDDA version 01 is supported in Kernel7. 4.3.1 Input Table 4-7 lists the SDA-related data in the Kernel used for Offline Data Authentication. Table 4-7 Offline Data Authentication--Terminal Data Data element Description Public Key Index (PKI) Identifies the Certificate Authority's public key in conjunction with the RID for use in offline static and dynamic data authentication.. CA Public Key The Kernel uses CA Public Key to unlock the Issuer PK Certificate to recover the Issuer Public Key. Registered Application Provider Identifier (RID) Part of AID (first 5 bytes), used to identify payment systems. Identifies the application provider and the CA public key in conjunction with PKI. Table 4-8 illustrates all Card data used for the Kernel to decide whether to perform SDA or fDDA. Table 4-8 Offline Data Authentication--Card Data Data element Description Application Interchange Profile (AIP) Including indicators:  Byte 1 bit 7 indicates that the card supports SDA;  Byte 1 bit 6 indicates that the card supports fDDA. CA PKI Used with the Registered Application Provider Identifier (RID) to identify which Private Key was used to encrypt the Issuer PK Certificate and which corresponding Public Key shall be used to recover the Issuer PK Certificate. Issuer Public Key Certificate Provided by the appropriate certification authority to the card issuer. When the Kernel verifies this data element, it authenticates the Issuer Public Key plus additional data. Issuer Public Key Exponent Provided by the issuer and used to retrieve signed static application data and ICC PK certificate. Issuer Public Key Remainder Includes the part of issuer public key which is not listed in Issuer public key certificate EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 32 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Data element Description Registered Application Provider Identifier (RID) Part of AID (first 5 bytes), used to identify payment systems. Identifies the application provider and the CA public key in conjunction with PKI. Signature Static Application Data (SAD) A signature used in the validation of the card’s static data. The SAD is signed with the Issuer Private Key a nd is placed on the card during the personalization process. Static data authentication tag list This is an optional data which contains the tag of the Application Interchange Profile (AIP) if it is to be signed. Tags other than the tag of the AIP shall not be present in the SDA Tag List. The AIP shall be included in the SDA Tag List if SDA, DDA, or CDA is supported. This data element is used for SDA, DDA and CDA. ICC Dynamic Data Data specified by Issuer and included in signed dynamic application data. ICC Dynamic Number ICC dynamic number is the first data element of the ICC dynamic data. The ICC dynamic number contains a time- variant generated by the ICC. ICC PK Certificate ICC PK Certificate is created using the Issuer Private Key and placed in the card during card personalization. ICC PK Certificate contains the ICC public key and a hash of static application data. ICC PK Exponent Used to recover the Signed Dynamic Application Data, with the value of 3 or 65537. IC Card Public Key Remainder Part of the ICC PK which is not contained in the ICC PK Certificate (if any) Signed Dynamic Application Data The Signature generated by the card on receiving GPO command. 4.3.2 Kernel Processing EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 33 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – fDDA Version Check 4.3.2.1 The Kernel shall support fDDA. If Kernel7 supports fDDA, Then the Kernel shall check the fDDA version in the Card. See 4.3.2.2; Else fDDA verification failed, and the Kernel continues with the subsequent procedure in case that fDDA failed or not performed, see 4.3.2.5. 4.3.2.2 The card shall support fDDA. If the Application Interchange Profile (AIP) indicates that the card supports DDA (AIP Byte 1 bit 6 is "1"), Then the Kernel performs fDDA data check. See 4.3.2.3; Else fDDA verification failed, and the Kernel continues with the subsequent procedure in case that fDDA failed or not performed, see 4.3.2.5. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 34 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – fDDA Data Check 4.3.2.3 The Kernel is responsible to ensure that all fDDA related data exist. Table 4-9 illustrates all the dynamic Kernel data to be hashed. Card Authentication Related Data includes a card unpredictable number and Card Transaction Qualifiers. As one of the Terminal Dynamic Data elements, the card shall generate a card unpredictable number and pad the Card Transaction Qualifiers into Card Authentication Related Data. Note: If the Card Transaction Qualifiers is not placed in the card during personalization, then the card shall set the value as zero for use in Card Authentication Related Data. Table 4-10 illustrates the data elements in ICC Dynamic Data. If any data element listed in Table 4-9 and Table 4-10 is missing, Then fDDA verification failed, and the Kernel continues with the subsequent procedure in case that fDDA failed or not performed, see 4.3.2.5. Else, the Kernel performs fDDA verification, see 4.3.2.4. Table 4-9 Dynamic Kernel Data to be Hashed Data element Tag Length Source Unpredictable number 9F37 4 bytes Kernel Authorized amount 9F02 6 bytes Kernel Transaction currency code 5F2A 2 bytes Kernel Card Verification Related Data 9F69 Variable Card Note: Card verification related data is variable-length data. Reader shall perform dynamic signature authentication using the entire card verification related data returned by card. EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 35 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Table 4-10 IC Card Dynamic Data to be Hashed Tag Data element Length Source 9F36 Application Transaction Calculator (ATC) 2 bytes Card Requirement – fDDA Verification 4.3.2.4 The Kernel performs fDDA verification. 1. Obtain CA public key, this process conforms to Chapter 6.2 of [EMV Book2]. 2. Recover Issuer public key, this process conforms to Chapter 6.3 of EMV Book2. 3. Recover IC card public key, this process conforms to Chapter 6.4 of [EMV Book2]. 4. Verify dynamic signature, this process conforms to Chapter 6.5 of [EMV Book2], except the following contents: If the Card Verification Related Data (Tag "9F69") is returned, And the length of the Card Verification Related Data (Tag "9F69") is more than or equal to 8 bytes and less than or equal to 16 bytes, And the first byte of the Card Verification Related Data (Tag "9F69") is “01”, then the Kernel continues with the following steps in fDDA verification; Else fDDA verification failed, and the Kernel continues with the subsequent procedure in case that fDDA failed or not performed, see 4.3.2.5. If the cryptogram type is an ARQC, then the kernel shall check the value of the Signed Data Format is '95'. If it's not '95', the fDDA verification failed. Dynamic Kernel data elements to be hashed shall not be specified in DDOL (DDOL is an unidentifiable data in the Kernel), instead they are coded in sequence as specified in Table 4-9. If the card returns DDOL, EMV Contactless Specifications for Payment Systems Kernel 7 Specification v2.12 Page 36 / 66 © 2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV ® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Requirement – fDDA Verification Then the Kernel ignores the data object, and shall not terminate the transaction. If the cryptogram type is not ARQC, Then If fDDA verification is successful and, Then the Kernel offline approve the transaction by providing an Approved Outcome, see 4.5.1. Else fDDA verification failed, and the Kernel continues with the subsequent procedure in case that fDDA failed or not performed, see 4.3.2.5. Note：In online transactions with offline data authorisation, the special terminals may perform specific actions based on the results of fDDA verification on online processing; this is out of the scope of this document. Requirement – fDDA Failed or Not Performed 4.3.2.5 The issuer may request an Online processing if fDDA failed or not performed besides terminating the transaction. The Kernel needs