EMV® Terminal Type Approval – Contact Level 2 – Administrative Process

EMV® Terminal Type Approval Contact Level 2 __________________________________________________ Administrative Process Version 2.15 June, 2026 © 2021-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® Terminal Type Approval Level 2 Administrative Process Page i / v Legal Notice This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. 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 THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document 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 this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document 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 this document 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 this document. © 2021-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® Terminal Type Approval Level 2 Administrative Process Page ii / v Revision Log – Version 2.15 The following changes have been made to the document since the publication of Version 2.15. Section Reason for change Clarification in section 2.10 Adding Note in section 5.1 and 5.2 © 2021-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® Terminal Type Approval Level 2 Administrative Process Contents Page iii / v 1 INTRODUCTION ............................................................................................................................... 1 1.1 AUDIENCE ......................................................................................................................................... 1 1.2 NORMATIVE REFERENCES ................................................................................................................. 1 1.2.1 Normative references ................................................................................................................ 2 1.2.2 EMV Specifications ................................................................................................................... 2 1.3 DEFINITIONS...................................................................................................................................... 3 1.4 NOTATIONAL CONVENTIONS ............................................................................................................. 7 1.4.1 Abbreviations ............................................................................................................................ 7 1.4.2 Terminology & conventions ...................................................................................................... 8 2 TYPE APPROVAL OVERVIEW ...................................................................................................... 9 2.1 SCOPE OF CONTACT TYPE APPROVAL LEVEL 2 ................................................................................. 9 2.2 TYPE APPROVAL DOCUMENTATION ................................................................................................ 12 2.3 EMV LEVEL 2 APPLICATION SOFTWARE APPROVAL ...................................................................... 12 2.3.1 EMV Application Kernel ......................................................................................................... 13 2.3.2 EMV Application Kernel - Level 2 Approval Prerequisites .................................................... 14 2.3.3 Terminal and EMV Application Kernel Relationships ............................................................ 14 2.3.4 Case of Virtual Machine identified as Operating System........................................................ 15 2.4 LEVEL 2 TYPE APPROVAL LIFE CYCLE CONCEPT............................................................................ 15 2.4.1 EMV Life Cycle and Type Approval Milestones...................................................................... 15 2.4.2 Design and Debugging Phase ................................................................................................. 16 2.4.3 Application Kernel Type Approval Phase ............................................................................... 16 2.4.4 Application Kernel Approval: ................................................................................................. 16 2.4.5 Level 2 Application Software Approval Resubmission Phase ................................................. 17 2.4.6 End of Design Life................................................................................................................... 17 2.5 EMV LEVEL 2 CONFIGURABLE APPLICATION KERNEL TESTING ............................................... 17 2.5.1 Prerequisites – Configurable Application Kernel ................................................................... 17 2.5.2 Configurable Application Kernel - Additional Prerequisites .................................................. 18 2.5.3 Initial submission - Configurable Application Kernel ............................................................ 18 2.5.4 Resubmission – Configurable Application Kernel .................................................................. 22 2.5.5 General rules concerning Configurable Application Kernels................................................. 23 2.6 SPLIT APPLICATION KERNEL TESTING ............................................................................................. 24 2.6.1 Resubmission – Sub Component Change Process................................................................... 24 2.6.2 Case of change of a transparent sub component..................................................................... 25 2.7 APPLICATION KERNEL TESTING WITH MULTIPLE PIN PAD SUPPORT ............................................... 25 2.7.1 PIN Pad and Application Kernel relationship - Prerequisites ................................................ 25 2.7.2 PIN Pad Change Process- Additional Prerequisites............................................................... 25 2.7.3 Initial submission - PIN Pad Change Process ........................................................................ 26 © 2021-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® Terminal Type Approval Level 2 Administrative Process Page iv / v 2.7.4 Resubmission –PIN Pad Change Process ............................................................................... 26 2.7.5 Case of single external PIN Pad ............................................................................................. 27 2.7.6 Case of PIN Pad without EMV function on board (transparent PIN Pad) ............................. 27 2.8 MERGING CONFIGURABLE KERNEL PROCESS AND MULTIPLE PIN PAD PROCESS ............................ 28 2.8.1 Prerequisites ........................................................................................................................... 28 2.8.2 Initial submission .................................................................................................................... 29 2.8.3 Resubmission – Adding a Configuration or a PIN Pad........................................................... 29 2.8.4 Resubmission – Adding a Combination................................................................................... 29 2.8.5 General rule ............................................................................................................................ 30 2.9 APPLICATION KERNEL TESTING WITH MULTIPLE OPERATING SYSTEM SUPPORT............................. 30 2.9.1 Prerequisites ........................................................................................................................... 31 2.9.2 Initial submission .................................................................................................................... 31 2.9.3 Resubmission........................................................................................................................... 31 2.10 APPLICATION KERNEL WITH PLATFORM DEPENDENCIES: MULTIPLE PLATFORM SUBMISSION ........ 32 2.10.1 Initial submission .................................................................................................................... 32 2.10.2 Resubmission – New Terminal with the same platform dependencies .................................... 32 2.11 APPLICATION KERNEL TESTING SUMMARY ..................................................................................... 33 2.11.1 EMVCo terminal type approval testing structure ................................................................... 33 2.11.1 Templates usage ...................................................................................................................... 38 2.12 ICS SUBMISSION RULES .................................................................................................................. 39 2.12.1 ICS Submission ....................................................................................................................... 39 2.12.2 ICS replacement ...................................................................................................................... 39 2.13 EMVCO TERMINAL TYPE APPROVAL FEE STRUCTURE ..................................................................... 40 2.14 INTEGRATED POINT OF SALE ........................................................................................................... 42 3 ROLES & RESPONSIBILITIES ..................................................................................................... 43 3.1 EMVCO .......................................................................................................................................... 43 3.2 EMVCO TYPE APPROVAL SECRETARIAT (CATA).......................................................................... 43 3.3 AUDITORS ....................................................................................................................................... 44 3.4 EMVCO RECOGNISED LABORATORIES ........................................................................................... 44 4 TYPE APPROVAL PROCEDURES ............................................................................................... 46 4.1 REGISTRATION ................................................................................................................................ 49 4.1.1 Contract with EMVCo............................................................................................................. 49 4.2 APPLICATION PROVIDER AND LABORATORY OPERATIONS.............................................................. 49 4.2.1 Contracts between Laboratories and Vendors ........................................................................ 51 4.2.2 Type Approval Test Report...................................................................................................... 51 4.2.3 Samples Management.............................................................................................................. 52 4.2.4 Case of samples not transferrable into Laboratory premises ................................................. 54 4.3 APPLICATION PROVIDER PREPARATION FOR APPROVAL REQUEST.................................................. 56 4.4 APPLICATION PROVIDER DOSSIER ................................................................................................... 56 © 2021-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® Terminal Type Approval Level 2 Administrative Process Page v / v 4.5 EMVCO REVIEW AND APPROVAL................................................................................................... 56 4.5.1 LoA identication and coding ................................................................................................... 56 4.6 APPROVAL WITH CONDITIONS............................................................................................... 57 4.7 TYPE APPROVAL RENEWAL PROCESS ............................................................................................. 58 4.7.1 Basic Policy............................................................................................................................. 58 4.7.2 Renewal Process – Configurable Application Kernel ............................................................. 61 4.7.3 Renewal Process – Multiple PIN Pads.................................................................................... 62 4.7.4 Renewal Process – Multiple Operating System....................................................................... 62 4.7.5 Level 1 Renewal versus Level 2 Renewal ................................................................................ 62 4.7.6 Labs for Renewal testing ......................................................................................................... 62 4.7.7 Samples submission................................................................................................................. 63 4.7.8 ICS Submission ....................................................................................................................... 63 4.7.9 Renewed Product vs Additional Configuration, OS and PIN Pad .......................................... 63 4.7.10 Restricted Renewed Product vs Additional Configuration, OS and PIN Pad ......................... 63 5 TEST VERSION AND SPECIFICATION CHANGE ................................................................... 63 5.1 TEST CHANGES WITHOUT SPECIFICATION UPDATE AND APPLICATION NOTE.................................. 64 5.2 TEST CHANGES DUE TO SPECIFICATION UPDATE AND APPLICATION NOTE ..................................... 65 5.3 TESTING APPLICABILITY.................................................................................................................. 66 6 APPLICATION KERNEL CHANGES ........................................................................................... 67 7 CHANGE IN CONTACT INFORMATION ................................................................................... 68 8 APPENDIX A: FINDING THE FORMS......................................................................................... 69 9 APPENDIX B: CHECKSUM RULES ............................................................................................. 69 © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 1 / 72 1 Introduction EMVCo, LLC (“EMVCo”) manages and maintains the EMV Integrated Circuit Card (ICC) Specifications for Payment Systems, hereinafter called the EMV Specifications. EMVCo established the terminal type approval process to create a limited mechanism to test compliance with the EMV Specifications. Type Approval provides an increased level of confidence that interoperability and consistent logical behavior between compliant applications have been achieved. EMVCo type approval testing is divided into two levels. The Level 1 type approval process tests compliance with electromechanical characteristics, logical interface, and transmission protocol requirements defined in part I of the EMV Specifications. Level 2 type approval tests compliance with debit/credit application requirements defined in the remainder of the EMV Specifications. This document describes the administrative process used to have card acceptance devices (terminals) tested for compliance with EMV level 2 requirements. The document outlines the fundamental concepts upon which EMV type approval is based, provides a summary of participating entities and their respective roles, and the detailed procedures by which a software provider can obtain EMVCo terminal level 2 type approval. 1.1 Audience The target audience of this document is: • Application Providers • Laboratory (recognised to perform the type approval tests) • Auditors (qualified to verify that laboratories comply with the EMVCo processes and procedures) Readers are reminded that type approval, when granted by EMVCo, shall not be construed as a warranty or representation of any sort, nor may it be relied upon by any party as an assurance of quality or functionality of any product or service. Please note the details of the legal notice incorporated in the front of this document for important limitations on the scope of type approval. 1.2 Normative References The following standards contain provisions that are referenced in this specification. The latest version including all published amendments shall apply unless a publication date is explicitly stated. © 2021-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® Terminal Type Approval Level 2 Administrative Process 1.2.1 Normative references Page 2 / 72 Ref.: ISO 9001/2 ISO 10011 ISO/IEC Document Identity ISO 9001/2 ISO 10011 ISO/IEC Guide 2 ISO DIS 17025 Document Title Quality Assurance Requirements Guidelines for Auditing Quality Systems — Part 1: Auditing General Terms and Their Definitions Concerning Standardization and Related Activities General Criteria for the Operation of Testing Laboratories/General Requirements for the Competence of Testing and Calibration Laboratories Version Latest version available Latest version available Latest version available 1.2.2 EMV Specifications EMVCo, LLC (EMVCo) manages and maintains the EMV Integrated Circuit Card (ICC) Specifications for Payment Systems and related specifications. As used in this document, “EMV Specifications” denotes all documents listed in Table 1-2. EMV Specifications are publicly available on the EMVCo website www.emvco.com. Table 1-2: EMV Specifications Document Title Version EMV 4.4 ICC Specification for Payment Systems Card Specification Terminal Specification Application Specification All applicable Specification Updates and Application Notes to the documents above as published on the EMVCo website EMVCo Type Approval – Terminal Level 2 Test Cases EMV Terminal Type Approval Bulletin 185 [TA185] EMV Terminal Type Approval Bulletin 11 [TA11] Version 4.4, October 2022 Version 4.4, October 2022 Version 4.4, October 2022 As identified on the EMVCo website Latest version available Latest version available Latest version available © 2021-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® Terminal Type Approval Level 2 Administrative Process Document Title EMV Terminal Type Approval Bulletin 31 [TA31] Version Page 3 / 72 Latest version available 1.3 Definitions The following terms are used in this specification: Table 1-3: List of terms Answer to reset (ATR): string of bytes sent by the ICC in response to the reset by the terminal. These bytes convey information to the terminal that defines certain characteristics of the communication to be established between the ICC and the terminal. Application protocol data a message sent from the IFD to the card or conversely. It may unit (APDU): contain either a command message or a response message. Auditor: independent, impartial entity that verifies test laboratory conformance to EMVCo-defined type approval procedures. Baseline: For kernels capable of supporting multiple configurations, the baseline is the primary configuration (configuration 1) that will be fully tested during the type approval process. The baseline shall be the configuration with the highest weight of options enabled. Card: a payment card as defined by a payment system. Checksum: A vendor-generated value (minimum 4 bytes) for each application kernel, and configuration. The checksum must be a unique value for each application kernel, derived from the entire application kernel and any files associated. Another checksum must be also unique for each configuration (in case of multiple configuration kernel) with the configuration features. The method or algorithm used for generating the checksum is left to the discretion of the vendor. For example, a vendor may choose to implement SHA-1 or CRC. These values shall be retrievable for each Applications Kernels, Software Modules or External Libraries when used by the Application kernel and this for comparative purposes. Refer to annex B for more detail on Checksum defined rules. This checksum requirement applies to static kernels, configurable kernels, and the PIN pad change process. EMVCo expects the checksum will provide a validation that a kernel application remains unchanged from the test state through deployment. Command: Compliance: a message that is sent by the terminal to the ICC to initiate an action and solicit a response from the ICC. see conformance © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 4 / 72 Conformance: Delta Testing: Device under test (DUT): Embossing: EMVCo: EMV application kernel: Function: Implementation conformance statement (ICS): Implementation test (IUT): under Integrated circuit card (ICC): Integrated circuit(s): Interface device (IFD): Interface module (IFM): IFM interoperability: International Organisation for Standardisation (ISO): Laboratory: meeting all the requirements including implemented optional requirements the difference between the test plan versions the product was approved against versus the current version of the test plan when the product is reaching its Renewal date system, module, part, or component actually tested or to be tested. characters raised in relation to the front surface of a card. The organisation that manages the EMV Specifications and their related testing processes. a software module, core, or library, forming part of an overall terminal application architecture, developed for exclusive support of the EMV debit/credit functions and application requirements. a process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. a form completed by the EMV application provider listing all optional functions - as specified in the reference specification - supported in the EMV application kernel. a virtual or abstract device, implementing the EMV specification, to be submitted for testing a card into which one or more integrated circuits are inserted to perform processing and memory functions. electronic component(s) designed to perform processing and/or memory functions. part of a terminal into which the ICC is inserted, including such mechanical and electrical devices that may be considered part of it. a virtual or abstract device that contains the necessary hardware and software to power the ICC and to support communication between the terminal and the ICC up to the transport layer. The three main functional components are the mechanical, electrical and logical ICC interfaces The minimum requirements as defined in EMV Specification permitting the ICC and the IFM to communicate with each other in a predictable and consistent manner. an international body that provides standards for financial transactions and telecommunication messages. ISO works in conjunction with the International Telecommunication Union (ITU) for standards that affect telecommunications. ISO supports specific technical committees and work groups to promulgate and maintain financial service industry standards a facility that performs type approval testing in compliance with EMVCo defined requirements and procedures. © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 5 / 72 Letter of recognition: written statement that confirms a testing laboratory is performing type approval tests in conformance with the rules defined by EMVCo. Letter of approval: written statement that documents the decision of EMVCo that a specified product type has demonstrated sufficient conformance to the EMV Specification on the date of it being tested. Level 1 test: the execution of a defined set of electrical, mechanical, and communication protocol tests versus requirements described in part 1 of the EMV 2000 Integrated Circuit Card Specification for Payment Systems. Magnetic stripe: the stripe on the physical card containing magnetically encoded information. Major modification: technical change to or addition to the EMV application kernel that implies that the application provider cannot guarantee continued conformance of the modified EMV application kernel with the requirements of the EMV specifications. Message: a string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. Minor modification: technical change to the functionality of the EMV application kernel that does not affect the functionality of the application kernel with respect to the requirements of the EMV specifications. Multiple Kernel: Configuration an application kernel capable of supporting multiple predefined functional configurations without requiring major modifications to the kernel. Also referred to as a configurable application kernel. Open system interconnection (OSI): a seven-layer model, defined by ISO/IEC 7498, for describing interconnected systems. The seven layers are the physical, data link, network, transport, session, presentation, and application layers. Procedure: specified way to perform a set of tasks. Proficiency: ability of a testing laboratory to perform the specified tests in an exact and reproducible fashion and to provide an accurate test report. Protocol: method of communication between the ICC and the terminal, represented in this specification by T=0 (character protocol) and T=1 (block protocol). Prototype: implementation of a design for evaluation purposes. Type approval is not necessarily required. Recognition formal recognition by EMVCo that an auditor or testing laboratory is competent to carry out specific functions defined as defined by EMVCo type approval procedures. Reference specification (EMV Specifications): a set of documents defining the requirements to which the IFM or an application shall comply. The reference specification consists of the current EMV 2000 Integrated Circuit Card Specification for Payment Systems and any © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 6 / 72 additional documentation required to perform type approval. Registration number: Regression testing: Renewal : Request for approval: Response: Restricted Renewal : Sample: Selected test Cases Service provider: Single-Configuration Kernel: Split Application Kernel: Sub Component: System integrator: System under test (SUT): Terminal application layers (TAL): unique identification number assigned by EMVCo to an IFM or application provider. a predefined subset of functional test cases (Regression template) executed to determine whether changes have been made to the originally approved product. Regression Testing may be performed when Delta Testing is not required extension given to the Application Kernel Approval at the end of its validity date after evaluation that the specified product has demonstrated sufficient conformance to the current EMV specification at the time of the Renewal a form that accompanies the results from a tested EMV application kernel submitted to EMVCo for type approval. a message returned by the ICC to the terminal after the processing of a command message received by the ICC extension given to the Application Kernel Approval at the end of its validity date, after failing full Renewal testing. Specified product has demonstrated sufficient conformance to current, critical EMV functionality at the time of the Renewal a terminal, including the IUT, picked out of production for testing. It is the set of test cases to run for the Kernel Activated Options or Deactivated Options (also named added or removed functions), made by the Options difference between the Baseline Configuration and the Additional Configuration under test the entity that provides a product or a service to customers, using terminals and a payment system. an application kernel capable of supporting only a single predefined functional configuration. Also referred to as a static application kernel a Application kernel residing on multiple physical independent components a physical independent part of the Device under Test in case of a Split Application Kernel architecture (such as POS + PIN Pad or Server + POS + PIN Pad). the entity that integrates IFM(s), devices containing IFM(s), and/or EMV applications kernels or any other application software, into a system for use by a service provider. system, module, part, or component actually tested or to be tested (either a part of the terminal or the entire terminal), including the IUT. the part of the terminal that initiates a command. It sends an instruction via the terminal transport layer (TTL) to the ICC in the form of a 5-byte header called the command header. © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 7 / 72 Terminal: Test: Test bench: Test case: Test Report: Type approval: Type approval documentation: Type approval process: Type approval test: Type approval test information Type approval test report: the device used in conjunction with the ICC at the point of transaction to perform a financial transaction. It incorporates the IFD, EMV application kernel, and may also include other components and interfaces, such as host communications. any activity that aims at verifying the conformance of a selected product or process to a given requirement under a given set of conditions. a defined combination of a set of test methods and test equipment used for type approval tests a description of the actions required to achieve a specific test objective. the report containing the results of testing performed on an EMV application kernel by an EMVCo recognised test laboratory. acknowledgment by EMVCo that the specified product has demonstrated sufficient conformance to the EMV specification for its stated purpose. full set of documents and procedures issued by EMVCo to enable the type approval process. Section 2.2 provides the list of documents associated with terminal Level 2 type approval. the processes, procedures and tests associated with verifying that a product complies with the specification. the execution of a defined set of tests against requirements described in a specification to determine compliance with that specification. list of documents and procedures provided to the testing laboratories to facilitate the type approval process. a document containing the results yielded from type approval testing of a product. 1.4 Notational conventions 1.4.1 Abbreviations The abbreviations listed in Table 1-4 are used in this specification. Table 1-4: Abbreviations Term Definition APDU Application protocol data unit ICC Integrated circuit card ICS Implementation conformance statement © 2021-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® Terminal Type Approval Level 2 Administrative Process IFD IFM ISO IUT Lab TAL TBI TTA Page 8 / 72 Interface device Interface module International Organisation for Standardisation Implementation under test Laboratory Terminal application layer Test bench implementation Terminal type approval 1.4.2 Terminology & conventions The following words are used often in this specification and have a specific meaning: Shall Defines a product or system capability which is mandatory. May Defines a product or system capability which is optional or a statement which is informative only and is out of scope for this specification. Should Defines a product or system capability which is recommended. The following conventions apply: Value of Parameters Throughout the specification, symbols are used to identify the values of parameters. The permitted values of the parameters are listed in Annex A and are written in Arial bold to distinguish them in the text. When used to define timings, frequencies, etc., it is the actual value that is intended. For example fc is the actual carrier frequency from the PCD. © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 9 / 72 2 Type Approval Overview 2.1 Scope of Contact Type Approval Level 2 EMVCo terminal type approval Contact Level 2 establishes an increased level of confidence that application providers have understood and can successfully implement the EMV specifications. Application providers submit their card acceptance device (terminal) with the application software and appropriate documentation, including the Implementation Conformance Statement (ICS), to an EMVCo recognised laboratory for testing. The laboratory executes a set of EMVCo-defined test cases and prepares a test result document for the application provider that may then be submitted to EMVCo for evaluation. EMVCo’s evaluation of the test results concludes with the issuance of a letter of approval or decline notification. Software architecture, identification and version control is outside the scope of the EMV Specifications. The software component(s) supporting the required EMV specification functionality is called the EMV application kernel – discussed in more detail in section 2.3 of this document. The application provider is required to identify the EMV application kernel and assign it a unique label according to the application provider’s naming conventions. Approval, when granted, applies to the vendor-supplied EMV application kernel identification. Major changes or additions to the EMV application kernel create a new unapproved kernel that requires re-testing and approval before EMV compliance can be claimed. Common industry practice requires application providers to accommodate local acquirer requirements in their card acceptance devices. These acquirer requirements are outside of scope for EMVCo type approval. Terminal software architecture plays a significant role in determining whether complying with non-EMV acquirer requirements have the potential to impact the EMV application kernel. EMVCo limits type approval to the EMV application kernel, leaving the responsibility to the appropriate local acquiring entity (also referred to as the owner of the environment of use) to validate continued compliance with the EMV specification functionality in the integrated acquiring environment. Obtaining an EMV application kernel approval from EMVCo has the advantage that:  Acquirers have access to terminal implementations in respect of which compliance to the EMV specifications has already been tested - yielding a likely reduction in testing costs as well as improved time to market for final implementations  Application providers can sell standard terminal implementation kernels on a worldwide basis and differentiate themselves from the competition. Figure 2.1 below illustrates the various functional components usually contained in terminal software. This is for illustration purposes only and a rigid function separation as shown is not required and is unlikely to exist in a specific implementation. The diagram differentiates between EMVCo-defined functions and other terminal capabilities determined by the acquirer or other local entity. EMVCo level 1 and level 2 testing is also illustrated. © 2021-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® Terminal Type Approval Level 2 Administrative Process Figure 2.1: Terminal Component Illustration Page 10 / 72 Acquirer and/or National Payment System Specifications are not part of Level 2 EMV Specifications EMV L2 EMV L1 Online Interfaces Acquirer settings Product settings EMV D/C Application other application(s) settings Other application(s) EMV Security EMV Application Selection EMV Command set IFM In scope for terminal EMV level 2 testing and approval are the card to terminal application interface and terminal functionality as described in the EMV specifications. The acquirer, and payment system requirements used to complete transaction processing are outside of scope. Figure 2.2 shows at a higher level how the terminal relates to the total environment necessary to facilitate debit/credit transactions. Terminal Level 2 type approval is limited to the interaction between card and terminal. The acquirer to issuer online communication illustrated is not part of the type approval test environment. However, some test cases require communication external to the terminal to complete the card to terminal interaction. To facilitate these tests, an emulator is necessary to test the external communication. © 2021-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® Terminal Type Approval Level 2 Administrative Process Figure 2.2: Level 2 testing CARD TERMINAL LEVEL 2 Page 11 / 72 SERVER ACQUIRER Payment SNysettwemork ISSUER HOST SYSTEM Responsibility of the acquirer/payment system © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 12 / 72 2.2 Type Approval Documentation The type approval process is based on set of documents referred to as type approval documentation. Figure 2.3 illustrates the available type approval documents and intended readers. Figure 2.3: Type approval documentation The titles of the individual documents referred to in Figure 2.3, are listed below: EMVCo Type Approval - Terminal Level 2 - Administrative Process EMVCo Type Approval - Terminal Level 2 - Test Requirements EMVCo Terminal Type Approval - Level 2 - Test Cases EMVCo Type Approval - Terminal Level 2 - Laboratory Requirements EMVCo Type Approval - Terminal Level 2 - Implementation Requirements EMVCo Type Approval – Terminal Level 2 – Laboratory Recognition Procedure 2.3 EMV Level 2 Application Software Approval EMV Level 2 application software refers to hardware-resident software developed by a vendor to support all required and optional features as it is described in the EMV specifications. The EMV Level 2 application software forms part of the overall terminal application, which may (and often does) contain additional proprietary functionality. The EMV Level 2 terminal type © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 13 / 72 approval process focuses on testing the component(s) or part of the application that supports the EMV functionality The architecture used by the application provider in the software design determines whether it is possible to isolate the EMV Level 2 component(s) from other software functionality in the device for testing and approval. This, in turn, dictates whether the approved EMV Level 2 component(s) can be approved generically for use on similar platforms or whether the approval is only applicable to one specific hardware/software platform. Vendors may choose to use software architecture that supports a modular approach and in such a way facilitate a focused approach that eliminates the need for repetitive Level 2 type approval testing. 2.3.1 EMV Application Kernel An EMV application kernel can be described as a software module or set of modules, core, or library, forming part of an overall terminal application architecture, developed for exclusive support of the EMV debit/credit functions and application requirements. An application may qualify as an EMV application kernel and get approved as such if it is constructed using an architecture similar to those discussed in EMV terminal specification Book 4 section 8, i.e., an Application Program Interface (API) or an interpreter/virtual machine approach. These approaches allow the EMV application libraries/modules to be isolated so that the same libraries/modules could be used over various hardware/software platforms utilising the same operating system or virtual machine platform without any change. Where supported by the terminal software architecture, an approved EMV application kernel has the added advantage for the purchasing community that the overall terminal application can be maintained and modified without impacting the EMV functions - eliminating the need for EMV Level 2 Type testing and approval following any change to related or unrelated areas in the software. EMVCo’s Level 2 Type Approval testing is focused on the EMV functionality supported in the terminal as demonstrated by the terminal’s ability to communicate with an EMV card in a predictable and reliable fashion. The EMV Level 2 test cases are thus conducted against an application provider’s identified EMV application libraries, core or module, for a particular terminal. Supplementary functionality necessary for comprehensive testing such as terminal to acquirer message formats, communications protocols, terminal prompt sequences or payment system settings may be emulated by the application provider. The implementation being tested may thus not necessarily represent the end product since it is to be expected that some level of customisation will be required for each market and/or acquirer. Application kernels may be developed to function as either static or configurable components. Single-configuration kernels are defined as either being static components without configurable options or kernels that require major modifications (such as recompiling of software) to change functional settings. Multiple configuration kernels are those capable of supporting multiple functional configurations without requiring major modifications to the kernel. Regardless of whether an application kernel is capable of supporting single or multiple configurations, any supported configurations must be tested and approved by EMVCo prior to their deployment and use. An abstract example of the terminal software utilising EMV application libraries is illustrated below Figure 2.4: EMV Application Kernel Concept © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 14 / 72 EMV DebTiEtRMaINnALd Credit Applications Other Applications PPaayymmeenntt SScyhsetemme SSeettttiinnggss Message Formats Terminal Prompts Communication Protocol NonFinancial Applications Purse Applications The advantages to identifying the various layers of terminal software include the ability for a vendor to: • Obtain a single EMV Level 2 application kernel approval based on tests performed at an independent laboratory. • Allow for subsequent software modification and customisation of software components co-resident with the EMV application kernel in the terminal without requiring additional EMVCo testing. • The EMV application kernel also provides the ability to extend the Level 2 approval to a family of terminals utilising an EMVCo Level 1-approved Interface Module (IFM), terminal software platform and EMV application kernel (see Terminal and EMV Application Kernel Relationships – One Application to Many Terminals). 2.3.2 EMV Application Kernel - Level 2 Approval Prerequisites The following are required for an application provider to obtain an EMV application kernel approval: • Level 1 approval of the Interface Module (IFM) being used in the terminal hardware configuration submitted for level 2 testing. The IFM used in the terminal under test shall have a valid LoA at the time of the initial submission. • Signed contract between application provider and EMVCo • Payment for EMVCo administrative fees 2.3.3 Terminal and EMV Application Kernel Relationships One Application to One Terminal In some integrated configurations, the EMV application kernel is platform dependent and not © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 15 / 72 portable to any other terminal platforms. To port the application requires the core library to be rewritten or recompiled. Some identified cases where the EMV Application Kernel is platform dependent and so with a limited portability are: • Random Generator functions performed by a specific Hardware of the terminal platform (e.g. the Random generation is not a software module). • Cryptographic functions performed by a specific Hardware of the terminal platform (e.g. the RSA is not a software module). This portability limitation of the EMV Application Kernel will be mentioned on the Letter of Approval. Note: Real Time Clock function is not considered an EMV function. Therefore even if this RTC function is performed by a Hardware component it is not a platform dependent function of the Application Kernel (so no portability limitation of the Application Kernel if RTC is performed by a specific Hardware). One Application to Many Terminals In this configuration, a single application may be portable over a number of related platforms. However, the related platforms must all utilise the same operating system or virtual machine configuration. Please reference EMV Terminal Type Approval Bulletin 11 [TA11] obtainable from the EMVCo website for additional information concerning the portability of kernels. 2.3.4 Case of Virtual Machine identified as Operating System Virtual Machine are considered by EMVCo as an Operating System, and so identified as such in the LoA. If the Product Provider identifies the Virtual Machine in the ICS, it will be referenced as the OS in the LoA of the Product. Advantage of VM identified as OS is that porting the Application Kernel within another device with a different OS but with the same Virtual Machine and VM version, does not require testing as the Multiple OS process is not required. This apply today only on the Java Virtual Machine. 2.4 Level 2 Type Approval Life Cycle Concept The following sections identify the type approval life cycle which is a logical concept regarding the design and key approval milestones of a Level 2 product. 2.4.1 EMV Life Cycle and Type Approval Milestones Type Approval shall be done on the definitive version of the Application Kernel loaded on a Level 1 approved product. Therefore, the Type Approval milestone shall occur at a particular moment in the Product Life cycle: (Figure 5). Figure 2.5: Life cycle of an application software © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 16 / 72 terminal design Debugging EMVCo Type Approval *with representative Sample Approval duration EMVCo Type Approval Resubmission EMVCo Type Approval Renewal In situation where the Application Provider wants to add subsequent configurations, Pin Pads or OS Renewal duration EMVCo Type Approval Renewal/ Restricted Renewal Start of design phase End of debugging phase : Out of scope of EMVCo Type Approval Start of deployment phase End of first approval Start of renewed approval 2.4.2 Design and Debugging Phase The Application Kernel is developed by the Application Provider or an entity directly related to the Application Provider. Most importantly, Application Kernel shall be designed and developed in accordance with the EMV Specifications, as well as any other applicable specifications (e.g. government standards). Before starting deployment, implementations of the Application Kernel must be submitted for type approval test to demonstrate conformance with the required specifications. 2.4.3 Application Kernel Type Approval Phase EMVCo appraises conformance of the Application Kernel design against the EMV Specifications. To determine conformance, reference implementations of the Application Kernel type must undergo predefined tests in a specified test environment (test laboratory). The Application Kernel submitted to Test Laboratory shall be loaded in a Level 1 approved product and must be representative of final deployment. After the Letter of Approval has been granted, it is valid as long as the following applies: • The design and implementation of the deployed Application Kernel is the same as it was within the Samples, which was tested and approved. • The approval is not revoked by EMVCo. • The Letter of Approval is not expired Any change in the Application Kernel design as specified in the section titled Application Kernel Changes of this document, may create a new Application Kernel, whether it occurs before, during, or after deployment. Type Approval of that new Application Kernel is not presumed. Please refer to EMV Terminal Type Approval Bulletin 11 [TA11] for a description of minor and major changes as well as EMV Terminal Type Approval Bulletin 31 [TA31] for functions/capabilities that can be hidden without EMVCo requires re-approval of the Application Kernel. 2.4.4 Application Kernel Approval: 2.4.4.1 Renewal Phase Prior to the Renewal date, vendors may request a Renewal by submitting the originally approved product to EMVCo for Renewal testing. The purpose of this Renewal testing is to © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 17 / 72 ensure that products pass the most current EMVCo testing. By passing the Renewal test, the product will receive a 4-year extension to the Letter of Approval. Products not passing Renewal testing can apply for a Restricted Renewal. Otherwise, after the Renewal date, they will be removed from the approved products list, and their Letter of Approval will be considered revoked. Should there be a case where a product reaches its Renewal date without any applicable test plan updates, such products will be issued an extension to their Letter of Approval without taking Renewal testing if vendors pay the Renewal fee by the Renewal date. 2.4.4.2 Restricted Renewal Phase Products which fail full Renewal testing are eligible to apply for a one-time Restricted Renewal. The failed test case results from the product’s full Renewal test session can be submitted for a Restricted Renewal approval. A product which demonstrates sufficient conformance to critical EMV functionality will be assigned a Restricted Renewal and listed as such on the EMVCo website on a dedicated list. Products not passing Restricted Renewal testing will be removed from the approved products list, and their Letter of Approval will be considered revoked, after the Renewal date. Only products which have previously failed full Renewal testing will be considered for a Restricted Renewal. A product having already been approved for a 4-year extension as a Restricted Renewal will not be eligible to apply for a further Restricted Renewal. 2.4.5 Level 2 Application Software Approval Resubmission Phase Vendors may wish to add subsequent configurations, or Pin Pads or OS to their originally approved product. The purpose of this resubmission testing is to assure that these additional features pass the most current EMVCo testing. After successful resubmission test, the Letter of Approval of the Product will be updated with the approval numbers of the new features. 2.4.6 End of Design Life The end of the design life of Product Approval is reached when deployment of that type is finally stopped. 2.5 EMV Level 2 CONFIGURABLE Application Kernel testing Unless explicitly stated otherwise, all rules governing configurable application kernels apply to products submitted for Renewal testing. 2.5.1 Prerequisites – Configurable Application Kernel Traditionally, EMVCo has functionally tested application kernels as static functional components with fixed or predefined settings. In recognition that application providers may develop a single kernel capable of functioning in a number of different configurations, EMVCo has revised its kernel testing policy in the following ways to better accommodate the needs of the industry and vendor community. EMVCo will now allow for application providers to define, submit, and test application kernels for multiple pre-defined configurations with the same test submission. While an initial “baseline” configuration (Configuration 1) will be fully tested, all subsequent pre-defined © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 18 / 72 configurations will be subjected to limited incremental and regression testing. In the case where products are submitted for Renewal testing, the Baseline configuration will undergo delta testing. Subsequent configurations will be required to undergo delta testing as well. • EMVCo will also allow for kernels previously approved in the configurable kernel model to be retested for additional subsequent configurations. Note: this option is limited to application kernels that have never experienced testing errors. In addition, subsequent configuration testing is limited to kernels approved after the effective date of this policy change. • EMVCo will now require that a checksum (Minimum 4 bytes length) be generated and associated with each kernel, each configuration (in case of multiple configuration) and each PIN Pad. The method or algorithm used for generating the checksum is left to the discretion of the vendor. Refer to annex B for more detail on Checksum defined rules. EMVCo anticipates that vendors submitting multiple configurations for approval will incur the following benefits: • A reduction in the number of test scripts executed for each additional configuration submitted • A reduction of time needed for type approval of multiple configurations since subsequent configurations after the first will not be subject to the full battery of level 2 tests. • Cost reduction in the EMVCo administrative fees Note: Actual cost savings to the vendor will depend upon the number of configurations tested. EMVCo anticipates that there will be incremental savings to the vendor for each additional/successive configuration submitted for approval. 2.5.2 Configurable Application Kernel - Additional Prerequisites The following identify additional prerequisites for an application provider to obtain an approval for a multiple configuration kernel: • The kernel must have configurable options • Changing of options must not require any recompilation or linkage of the application kernel code • The laboratory shall be able to change the configuration easily • The vendor shall generate a unique checksum, as described above, for each supported configuration. See annex B for additional Information. 2.5.3 Initial submission - Configurable Application Kernel The following rules will be applied to configurable application kernels initially submitted to EMVCo for formal approval. These rules do not apply to Debug testing that may be conducted directly between the laboratory and vendor. • There is no limit to the number of configurations that may be submitted for type approval testing -- one or more configurations may be defined • All functional options and features of the configurable application kernel must be identified on the ICS as being either configurable or fixed • At the time a configurable application kernel is submitted for testing, the vendor shall define a “baseline” configuration. The baseline will be the configuration subjected to © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 19 / 72 the full suite of level 2 test cases. Additional configurations would then be subjected to a more limited suite of tests. The following rules are applied to determine the baseline configuration: o Submissions with a single configuration will be the baseline by default o When multiple configurations are submitted for testing, the configuration with the highest weight of options enabled shall be designated as the baseline • The laboratory must submit a copy of the completed ICS to EMVCo prior to performing type approval testing. EMVCo will review the statement for accuracy, archive the form for later comparison, and send an acknowledgement that the ICS is acceptable for testing. • During type approval testing, if errors are found to exist in the application kernel, the following rules are applied o If an error is encountered in the baseline configuration, the entire application kernel will be rejected for approval o If an error Is encountered in a subsequent configuration (non-baseline), the vendor may take one of the following actions:  The vendor may decide to correct the detected errors and resubmit the application kernel for testing  The vendor may submit only the baseline application for EMVCo approval  The vendor may submit the baseline application and any additional error-free configurations for EMVCo approval. However, such approval requests are subject to additional error analysis by EMVCo to ensure errors do not have a negative impact upon other configurations. The vendor must agree to incur any additional testing costs deemed necessary • If testing errors are encountered in either the baseline or additional configurations, that application kernel is then prohibited from later being submitted for resubmission testing of additional configurations or Renewal testing. The application kernel will be treated as a new kernel if it is submitted again for testing. • Approved application kernels are retained by the laboratory for a period of the LoA validity + 1 year as of the date of approval. The vendor is responsible for providing support as necessary to maintain the kernel in an operational state to accommodate any subsequent testing or analysis that may be deemed necessary by EMVCo. 2.5.3.1 Baseline Selection • Options are categorised by level of importance and each of them has an associated weight • The weight sum of all enabled options defines the weight of the Configuration • Configuration with the highest weight is the Baseline Configuration • Weight will be automatically computed by the ICS and the weight of each configuration are listed in the ICS Section VI, last row • Baseline shall be always entered in the ICS in the first column of section VI, config1 (note that this is not done automatically by the ICS) © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 20 / 72 To prepare the filling of the ICS, table below shows the weight of the options listed in the ICS: Options Weight Manual Key Entry 1 Magnetic Stripe 1 IC with Contacts 1 Plaintext PIN 10 Online Enciphered PIN (RSA ODE) 7 Signature (paper) 5 Offline Enciphered PIN 20 No CVM 5 Kernel supports Biometric 5 Kernel supports Finger biometric verified offline 1 Kernel supports Finger biometric verified online 1 Kernel supports Facial biometric verified offline 1 Kernel supports Facial biometric verified online 1 Kernel supports Palm biometric verified offline 1 Kernel supports Palm biometric verified online 1 Kernel supports Iris biometric verified offline 1 Kernel supports Iris biometric verified online 1 Kernel supports Voice biometric verified offline 1 Kernel supports Voice biometric verified online 1 SDA & DDA 20 Card Capture 1 Tran Type – Cash 1 Tran Type – Goods 1 Tran Type – Services 1 Tran Type – Cash Back 1 Tran Type - Inquiry 1 Tran Type – Transfer 1 Tran Type – Payment 1 Tran Type – Administrative 1 Tran Type – Cash Deposit 1 Keypad 1 Numeric Keys 1 Alphabetic and Special Character Keys 1 Command Keys 1 Function Keys 1 Print 1 Display 1 Code Table 10 1 Code Table 9 1 Code Table 8 1 Code Table 7 1 © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 21 / 72 Code Table 6 1 Code Table 5 1 Code Table 4 1 Code Table 3 1 Code Table 2 1 Code Table 1 1 PSE 1 Cardholder Confirmation 1 Preferred display order? 1 Partial AID Selection 1 Multi language? 1 EMV Language Selection method? 1 Common Character Set 1 Revocation of Issuer Public Key Certificate 1 Default DDOL 1 Bypass PIN Entry 1 Subsequent Bypass PIN Entry 1 Get Data for PIN Try Counter 1 Fail CVM 1 Amount known before CVM processing 1 Floor limit checking 1 Random Transaction Selection 1 Velocity Checking 1 Transaction Log 1 Exception File 1 Terminal Risk Management irrespective of AIP setting 1 Terminal Action Codes supported 1 Terminal Action Codes can be deleted or disabled 1 TAC/IAC-Default skipped when unable to go online 1 TAC/IAC-Default normal processing when unable to go online 1 Mode 1 : Req. CDA on ARQC + Req. CDA on 2nd GenAC after approved On 20 line authorisation Mode 2 : Req. CDA on ARQC + No Req. CDA on 2nd GenAC after approved 20 On line authorisation Mode 3 : No Req. CDA on ARQC + No Req. CDA on 2nd GenAC after 20 approved On line authorisation Mode 4 : No Req. CDA on ARQC + Req. CDA on 2nd GenAC after approved 20 On line authorisation Forced Online 1 Forced Acceptance 1 Issuer Referrals 1 Default TDOL 1 Amount and PIN entered on the same keypad 1 Is the ICC/Magstripe Reader combined? 1 © 2021-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® Terminal Type Approval Level 2 Administrative Process If Combined is Magstripe read first? Does the terminal support account type selection? ‘on fly’ script processing Is Issuer Script device limit > 128 bytes? Internal Date Management Does the terminal support Receipt? Page 22 / 72 1 1 1 1 1 1 2.5.4 Resubmission – Configurable Application Kernel The following rules will be applied to approve configurable application kernels later submitted to EMVCo for testing of additional (add-on) configurations: • If an approved configurable application kernel never encountered testing errors, it may be subsequently retested for additional configurations, as defined by the vendor. However, these configurations are subject to the following restrictions dependent on the original definition of configurable options: o Non-configurable options are restricted to the same setting that was originally tested o Configurable options may reflect any setting • The testing must be performed on samples already physically present at an EMVCo laboratory. o If the sample is no longer present or is otherwise inoperable (dead battery, etc), EMVCo may accept a replacement sample from the vendor for testing provided they have signed a statement stating that the replacement sample is identical in all respects to sample originally supplied to a laboratory for testing (same kernel without any modification, same checksum(s), ..). In this case the following testing is required:  Baseline: Full retesting of the Baseline.  Additional configurations: Standard testing (Regression and Selected testing) • Regression testing and Selected testing shall be performed. • The vendor may elect to have a different laboratory perform resubmission testing. The vendor must make the necessary arrangements to have the application kernel transported between laboratories. The vendor is responsible for incurring the costs associated with this transfer • If an error is encountered in a resubmission configuration, the vendor may submit any additional error-free configuration(s) for EMVCo approval. However, such approval requests are subject to additional error analysis by EMVCo to ensure errors do not have a negative impact upon other configurations – including all configurations previously approved for that kernel. If previously approved configurations are impacted by detected errors EMVCo may revoke those approvals. The vendor is responsible for any additional testing costs deemed necessary to make this determination • If errors are encountered during resubmission testing, the kernel is then prohibited from future resubmission or Renewal testing. Filling the ICS: ICS shall be submitted with the following parts filled as described below: © 2021-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® Terminal Type Approval Level 2 Administrative Process Page 23 / 72 - Part I (with Identical information as initial submission) - Part IIa (with Identical information as initial submission) - Part IIb: header shall be filled as initial submission, But PIN Pads shall not be described (PIN Pads section shall be left blank) - Part IIc shall be left blank - Part III (with Identical information as initial submission) - Part V (with Identical information as initial submission) - Part VI shall be filled with: First column: Baseline Configuration (01) copied from initial ICS Other columns: added configuration ONLY (not existing one), with new config numbers - Part VII (with Identical information as previous submission) Note 1: In case the Test Plan changed between an Initial Submission and the Resubmission of the Kernel, the current valid test plan is applicable as per section 5.3. Also on the resubmission of the additional configuration, testing is performed as per section 2.11.1 (Regression Template + Selected Test), no Delta testing required Note 2: Even in instances where the vendor opts not to formally apply to EMVCo for approval of additional configurations, any testing errors encountered will still be communicated to EMVCo by the laboratory and would prohibit the kernel from future submission or Renewal testing. Further, any reported errors could result in revocation of previously granted approvals if deemed necessary as a result of any error analysis performed by EMVCo. • Any kernel experiencing errors during resubmission testing will be treated as a n