PCI Watch

Tracking changes across the Payment Card Industry

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

v2.14.r Type Approval Process
Contact Acceptance Device

EMV® Terminal Type Approval Contact Level 2 __________________________________________________ Administrative Process Version 2.14.r September, 2025

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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ v Revision Log – Version 2.14.r The following changes have been made to the document since the publication of Version 2.14. Section Reason for change Editorial Updates

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process Contents

1. 1. 1.2. 1.2. 1. 1. 1.4. 1.4. 2. 2. 2. 2.3. 2.3. 2.3. 2.3. 2. 2.4. 2.4. 2.4. 2.4. 2.4. 2.4. 2. 2.5. 2.5. 2.5. 2.5. 2.5. 2. 2.6. 2.6. 2. 2.7. 2.7. 2.7.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ v 2.7. 2.7. 2.7. 2. 2.8. 2.8. 2.8. 2.8. 2.8. 2. 2.9. 2.9. 2.9. 2. 2.10. 2.10. 2. 2.11. 2.11. 2. 2.12. 2.12. 2. 2. 3. 3. 3. 3. 4. 4.1. 4. 4.2. 4.2. 4.2. 4.2. 4. 4.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process Page v / v 4. 4.5. 4. 4. 4.7. 4.7. 4.7. 4.7. 4.7. 4.7. 4.7. 4.7. 4.7. 4.7. 5. 5. 5.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process 1.2.1 Normative references

/ 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

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process Document Title EMV Terminal Type Approval Bulletin 31 [TA31] Version

/ 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

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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 Organization for Standardization (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 organization 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process IFD IFM ISO IUT Lab TAL TBI TTA

/ 72 Interface device Interface module International Organization for Standardization 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process Figure 2.1: Terminal Component Illustration

/ 72 Acquirer and/or National Scheme Specifications are not part of Level 2 Testing 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 network, 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.

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process Figure 2.2: Level 2 testing =;!> ST!UV:;Y YT@TYIC

/ 72 ?T!@T!;=ABV!T! GLHR"C* I:"*e%Pf V??BT!Iab?S ?c?STU !"#A%C#DED)D*HI%-I*." LMNODP"PQALHR"C*I#H#*"R

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 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 www.emvco.com. ® EMV® Terminal Type Approval Level 2 Administrative Process / 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 utilizing 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 customization 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 utilizing EMV application libraries is illustrated below Figure 2.4: EMV Application Kernel Concept

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 72 8!V:;"44PN/A*ND-# ?*M"E >44PN/A*ND-# +A,F"-*./M"F"."**N-%# !"##A%" CDEFA*# O"EFN-AP +EDF4*# 5DFFS-NT /A*ND- +ED*D/DP @D-T CN-A-/NAP >44PN/A*ND-# +SE#" >44PN/A*ND-# 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 customization 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 utilizing 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 www.emvco.com. ® EMV® Terminal Type Approval Level 2 Administrative Process / 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 utilize 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

www.emvco.com. ®

EMV® Terminal Type Approval Level 2 Administrative Process

/ 72 !"#AE)*"+%,C -"./,,%C, M1O34) RST")8TT#4VDE:;%!"+/.A%++ M1O34) RST")8TT#4VDE >"C";DE 1-(OI+*&+IA-(0P/#/(+P/(!""'I4&+IA-( R#A%I)/#(0&-+O(+A(&))(O*SO/7*/-+( 4A-8I9*#&+IA-O:(RI-(R&)O(A#(;