terminal type approval contact level 2 · 2017. 6. 19. · contact level 2 _____ administrative...

© 2017 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 Contact Level 2 __________________________________________________

Administrative Process Version 2.6 February, 2017

EMV® Terminal Type Approval Level 2 Administrative Process Page i / v


Legal Notice This document summarizes EMVCo’s present plans for evaluation services and related policies and 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 non-infringement. 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.

EMV® Terminal Type Approval Level 2 Administrative Process Page ii / v


Revision Log – Version 2.6 The following changes have been made to the document since the publication of Version 2.5. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise.

Section Reason for change

2.12 ICS replacement rules

- Sample retention rule change

2.10 Application Kernel portability when platform dependencies exist

2.5.3 Clarification that Baseline configuration is the configuration with the most activated options

- Renewal testing limited to delta testing (no more regression testing)

2.7.6 Clarification of Internal PIN Pad submission

2.11.1 Test Template usage clarification for MCK submission

4.2.3 Sample Management

4.2.4 Clarification of ATM case when sample cannot be in Laboratory premises

EMV® Terminal Type Approval Level 2 Administrative Process Page iii / v


Contents 1 INTRODUCTION ................................................................................................................................. 1

1.1 AUDIENCE .......................................................................................................................................... 11.2 NORMATIVE REFERENCES .................................................................................................................. 1

1.2.1 Normative references ................................................................................................................. 21.2.2 EMV Specifications .................................................................................................................... 2

1.3 DEFINITIONS ....................................................................................................................................... 31.4 NOTATIONAL CONVENTIONS .............................................................................................................. 7

1.4.1 Abbreviations ............................................................................................................................. 71.4.2 Terminology & conventions ....................................................................................................... 7

2 TYPE APPROVAL OVERVIEW ....................................................................................................... 92.1 SCOPE OF CONTACT TYPE APPROVAL LEVEL 2 .................................................................................. 92.2 TYPE APPROVAL DOCUMENTATION ................................................................................................. 112.3 EMV LEVEL 2 APPLICATION SOFTWARE APPROVAL ....................................................................... 12

2.3.1 EMV Application Kernel .......................................................................................................... 122.3.2 EMV Application Kernel - Level 2 Approval Prerequisites ..................................................... 142.3.3 Terminal and EMV Application Kernel Relationships ............................................................. 142.3.4 Case of Virtual Machine identified as Operating System ........................................................ 14

2.4 LEVEL 2 TYPE APPROVAL LIFE CYCLE CONCEPT ............................................................................. 152.4.1 EMV Life Cycle and Type Approval Milestones ...................................................................... 152.4.2 Design and Debugging Phase .................................................................................................. 152.4.3 Application Kernel Type Approval Phase ................................................................................ 152.4.4 Application Kernel Approval: .................................................................................................. 162.4.5 Level 2 Application Software Approval Resubmission Phase .................................................. 162.4.6 End of Design Life .................................................................................................................... 16

2.5 EMV LEVEL 2 CONFIGURABLE APPLICATION KERNEL TESTING ................................................ 172.5.1 Prerequisites – Configurable Application Kernel .................................................................... 172.5.2 Configurable Application Kernel - Additional Prerequisites .................................................. 172.5.3 Initial submission - Configurable Application Kernel ............................................................. 182.5.4 Resubmission – Configurable Application Kernel ................................................................... 192.5.5 General rules concerning Configurable Application Kernels ................................................. 20

2.6 SPLIT APPLICATION KERNEL TESTING .............................................................................................. 202.6.1 Resubmission – Sub Component Change Process ................................................................... 202.6.2 Case of change of a transparent sub component ..................................................................... 21

2.7 APPLICATION KERNEL TESTING WITH MULTIPLE PIN PAD SUPPORT ................................................ 212.7.1 PIN Pad and Application Kernel relationship - Prerequisites ................................................ 21

EMV® Terminal Type Approval Level 2 Administrative Process Page iv / v


2.7.2 PIN Pad Change Process- Additional Prerequisites ............................................................... 212.7.3 Initial submission - PIN Pad Change Process ......................................................................... 222.7.4 Resubmission –PIN Pad Change Process ................................................................................ 222.7.5 Case of single External PIN Pad .............................................................................................. 232.7.6 Case of Internal PIN Pad ......................................................................................................... 232.7.7 Case of PIN Pad without EMV function on board (transparent PIN Pad) .............................. 23

2.8 MERGING CONFIGURABLE KERNEL PROCESS AND MULTIPLE PIN PAD PROCESS ............................. 242.8.1 Prerequisites ............................................................................................................................. 242.8.2 Initial submission ..................................................................................................................... 242.8.3 Resubmission ............................................................................................................................ 242.8.4 General rule ............................................................................................................................. 25

2.9 APPLICATION KERNEL TESTING WITH MULTIPLE OPERATING SYSTEM SUPPORT .............................. 252.9.1 Prerequisites ............................................................................................................................. 252.9.2 Initial submission ..................................................................................................................... 252.9.3 Resubmission ............................................................................................................................ 26

2.10 APPLICATION KERNEL WITH PLATFORM DEPENDENCIES: MULTIPLE PLATFORM SUBMISSION ........ 262.10.1 Initial submission ..................................................................................................................... 262.10.2 Resubmission – New Terminal having the same platform dependencies ................................. 27

2.11 APPLICATION KERNEL TESTING SUMMARY ...................................................................................... 272.11.1 EMVCo terminal type approval testing structure .................................................................... 272.11.1 Templates usage ....................................................................................................................... 31

2.12 ICS SUBMISSION RULES .................................................................................................................... 322.12.1 ICS Submission ......................................................................................................................... 322.12.2 ICS replacement ....................................................................................................................... 32

2.13 EMVCO TERMINAL TYPE APPROVAL FEE STRUCTURE ...................................................................... 332.14 INTEGRATED POINT OF SALE ............................................................................................................ 35

3 ROLES & RESPONSIBILITIES ...................................................................................................... 363.1 EMVCO ........................................................................................................................................... 363.2 EMVCO TYPE APPROVAL SECRETARIAT (CATA) ........................................................................... 363.3 AUDITORS ......................................................................................................................................... 373.4 EMVCO ACCREDITED LABORATORIES ............................................................................................ 37

4 TYPE APPROVAL PROCEDURES ................................................................................................ 394.1 REGISTRATION ................................................................................................................................. 42

4.1.1 Contract with EMVCo .............................................................................................................. 424.2 APPLICATION PROVIDER AND LABORATORY OPERATIONS .............................................................. 42

4.2.1 Contracts between Laboratories and Vendors ......................................................................... 434.2.2 Type Approval Test Report ....................................................................................................... 444.2.3 Samples Management ............................................................................................................... 454.2.4 Case of samples not transferrable into Laboratory premises .................................................. 45

EMV® Terminal Type Approval Level 2 Administrative Process Page v / v


4.3 APPLICATION PROVIDER PREPARATION FOR APPROVAL REQUEST .................................................. 484.4 APPLICATION PROVIDER DOSSIER .................................................................................................... 484.5 EMVCO REVIEW AND APPROVAL .................................................................................................... 484.6 APPROVAL WITH CONDITIONS ................................................................................................ 494.7 TYPE APPROVAL RENEWAL PROCESS .............................................................................................. 50

4.7.1 Basic Policy .............................................................................................................................. 504.7.2 Renewal Process – Configurable Application Kernel .............................................................. 534.7.3 Renewal Process – Multiple PINPads ..................................................................................... 534.7.4 Renewal Process – Multiple Operating System ....................................................................... 544.7.5 Labs for Renewal testing .......................................................................................................... 544.7.6 Samples submission .................................................................................................................. 544.7.7 ICS Submission ......................................................................................................................... 54

5 TEST VERSION AND SPECIFICATION CHANGE .................................................................... 555.1 TEST CHANGES WITHOUT SPECIFICATION UPDATE AND APPLICATION NOTE .................................. 555.2 TEST CHANGES DUE TO SPECIFICATION UPDATE AND APPLICATION NOTE ..................................... 555.3 TESTING APPLICABILITY ................................................................................................................... 56

6 APPLICATION KERNEL CHANGES ............................................................................................ 577 CHANGE IN CONTACT INFORMATION .................................................................................... 588 APPENDIX A: FINDING THE FORMS .......................................................................................... 599 APPENDIX B: CHECKSUM RULES .............................................................................................. 59

EMV® Terminal Type Approval Level 2 Administrative Process Page 1 / 62


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 (accredited 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.



1.2.1 Normative references

Ref.: Document Identity

Document Title Version Doc. Date

ISO 9001/2 ISO 9001/2 Quality Assurance Requirements

2nd edition

1994

ISO 10011 ISO 10011 Guidelines for Auditing Quality Systems — Part 1: Auditing

1993 August 1993

ISO/IEC ISO/IEC Guide 2

General Terms and Their Definitions Concerning Standardization and Related Activities

6th edition

1991

ISO DIS 17025 General Criteria for the Operation of Testing Laboratories/General Requirements for the Competence of Testing and Calibration Laboratories

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 2 1.

EMV Specifications are publicly available on the EMVCo website: www.emvco.com.

Table 1-2: EMV Specifications

Document Title

Version

EMV 4.2 ICC Specification for Payment Systems Card Specification Version 4.3, June 2011

Terminal Specification Version 4.3, June 2011

Application Specification Version 4.3, June 2011

All applicable Specification Updates and Application Notes to the documents above as published on the EMVCo website

As identified on the EMVCo website

EMVCo Type Approval – Terminal Level 2

Test Cases Latest version available

EMV Terminal Type Approval Bulletin 185 Latest version available



1.3 Definitions The following terms are used in this specification:

Table 1.4: List of terms Accreditation 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.

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 unit (APDU):

a message sent from the IFD to the card or conversely. It may 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 that will be fully tested during the type approval process. The baseline shall be the configuration with the most options enabled by default.

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: a message that is sent by the terminal to the ICC to initiate an action and solicit a response from the ICC.

Compliance: see conformance

Conformance: meeting all the requirements including implemented optional requirements

Delta Testing: 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



Device under test (DUT):

system, module, part, or component actually tested or to be tested.

Embossing: characters raised in relation to the front surface of a card.

EMVCo: a Limited Liability Company established to maintain the EMV specifications and administer type approval against those specifications.

EMV application kernel:

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.

Function: a process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction.

Implementation conformance statement (ICS):

a form completed by the EMV application provider listing all optional functions - as specified in the reference specification - supported in the EMV application kernel.

Implementation under test (IUT):

a virtual or abstract device, implementing the EMV specification, to be submitted for testing

Integrated circuit card (ICC):

a card into which one or more integrated circuits are inserted to perform processing and memory functions.

Integrated circuit(s):

electronic component(s) designed to perform processing and/or memory functions.

Interface device (IFD):

part of a terminal into which the ICC is inserted, including such mechanical and electrical devices that may be considered part of it.

Interface module (IFM):

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

IFM interoperability:

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.

International Organization for Standardization (ISO):

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

Laboratory: a facility that performs type approval testing in compliance with EMVCo defined requirements and procedures.

Letter of accreditation:

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 Configuration Kernel:

an application kernel capable of supporting multiple pre-defined 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.

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 additional documentation required to perform type approval.

Registration number:

unique identification number assigned by EMVCo to an IFM or application provider.

Regression testing:

a predefined subset of functional test cases (template A to E) executed to determine whether changes have been made to the originally approved product. Regression Testing may be performed when Delta Testing is not required

Renewal : 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

Request for approval:

a form that accompanies the results from a tested EMV application kernel submitted to EMVCo for type approval.

Response: a message returned by the ICC to the terminal after the processing of a command message received by the ICC



Restricted Renewal :

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

Sample: a terminal, including the IUT, picked out of production for testing.

Service provider: the entity that provides a product or a service to customers, using terminals and a payment system.

Single-Configuration Kernel:

an application kernel capable of supporting only a single pre-defined functional configuration. Also referred to as a static application kernel

Split Application Kernel:

a Application kernel residing on multiple physical independent components

Sub Component: 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).

System integrator: 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 under test (SUT):

system, module, part, or component actually tested or to be tested (either a part of the terminal or the entire terminal), including the IUT.

Terminal application layers (TAL):

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.

Terminal: 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.

Test: any activity that aims at verifying the conformance of a selected product or process to a given requirement under a given set of conditions.

Test bench: a defined combination of a set of test methods and test equipment used for type approval tests

Test case: a description of the actions required to achieve a specific test objective.

Test Report: the report containing the results of testing performed on an EMV application kernel by an EMVCo accredited test laboratory.

Type approval: acknowledgment by EMVCo that the specified product has demonstrated sufficient conformance to the EMV specification for its stated purpose.

Type approval documentation:

full set of documents and procedures issued by EMVCo to enable the type approval process. Section 4.2 provides the list of documents associated with terminal Level 2 type approval.

Type approval process:

the processes, procedures and tests associated with verifying that a product complies with the specification.



Type approval test: the execution of a defined set of tests against requirements described in a specification to determine compliance with that specification.

Type approval test information

list of documents and procedures provided to the testing laboratories to facilitate the type approval process.

Type approval test report:

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.5: Abbreviations Term Definition

APDU Application protocol data unit

ICC Integrated circuit card

ICS Implementation conformance statement

IFD Interface device

IFM Interface module

ISO International Organization for Standardization

IUT Implementation under test

Lab Laboratory

OSI Open system interconnection

TAL Terminal application layer

TBI Test bench implementation

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



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 accredited 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 4.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 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.



Figure 2.1: Terminal Component Illustration

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

Acquirer settings

Product settings

EMV D/C Application

EMV Security

EMV Application Selection

IFM

other application(s)

settings

Other application(s)

EMV Specifications

Acquirer and/or National Scheme Specifications are not part of Level 2

Testing

EMV L1

EMV L2

EMV Command set

Online Interfaces



Figure 2.2: Level 2 testing

Responsibility of theacquirer/payment system

TERMINALCARD SERVERACQUIRER

LEVEL 2

ISSUER HOSTSYSTEM

Payment Network

2.2 Type Approval Documentation

The type approval process is based on set of documents referred to as type approval documentation. Figure 3 illustrates the available type approval documents and intended readers.

Figure 2.3: Type approval documentation

Administrative Process

Laboratory Requirements

Accreditation Procedure

Implementation Requirements

Requirements

Test Cases

All Participants

All Participants

All Participants

Laboratory Auditors EMVCo



Administrative Documents

Technical Documents

The titles of the individual documents referred to in Figure 3, are listed below:

EMVCo Type Approval - Terminal Level 2 - Administrative Process

EMVCo Type Approval - Terminal Level 2 - Test Requirements

EMVCo Type Approval - Terminal 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 Accreditation 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 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 Part II – Software Architecture, 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.

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

TERMINAL

MessageFormats

PaymentSchemeSettings

TerminalPrompts

Communi-cation

Protocol

EMV Debit andCredit Applications

OtherApplications

Non-Financial

Applications

PurseApplications

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

• Products being submitted for Renewal testing must have a valid LoA at the time the Renewal test cycle begins

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 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 an 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 Type Approval Bulletin #11 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 Porduct. 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

terminal design

Debugging

EMVCo Type Approval*with representative

Sample

EMVCo Type Approval

Renewal

EMVCo Type Approval

Renewal/ Restricted Renewal

Start of design phase Start of deployment phaseEnd of debuggingphase

Approval duration Renewal duration

End of first approvalStart of renewed approval

: Out of scope of EMVCo Type Approval

EMVCo Type ApprovalResubmission

In situation where the Application Provider wants to add subsequent configurations, Pin Pads or OS

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 Renewal date is not past

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 Type Approval Bulletin #11 for a description of minor and major changes as well as Type Approval Bulletin # 31 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 ensure that products pass the most current EMVCo testing. By passing the Renewal test, the product will receive a three year extension to the Letter of Approval.

Products not passing Renewal testing can apply for a Restricted Renewal. Alternatively, 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 cycle 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 three 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 kernel 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 market 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 will be fully tested, all subsequent pre-defined 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 full delta testing. Subsequent configurations will be required to undergo full 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 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 most functional 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.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

• Resubmission testing for additional configurations must be performed on kernels already physically present at an EMVCo laboratory. If the kernel is no longer present or is otherwise inoperable, EMVCo may accept a replacement kernel from the vendor for testing provided they have signed a disclaimer stating that the replacement kernel is identical in all respects to the kernel originally supplied to a laboratory for testing (without modification). For this reason, it is essential that vendors retain an exact and unaltered copy of the application kernel originally sent to the laboratory during the initial testing phase.

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

Note: 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 new kernel if submitted again for testing.

• If additional configurations are approved during resubmission testing, the laboratory will retain the application kernel for a period of the LoA validity + 1 year as of the date of approval of the new configuration(s).

• If in the Terminal used for testing, the IFM LoA validity has expired, resubmission is still acceptable.



2.5.5 General rules concerning Configurable Application Kernels Configurable application kernels may only be used with those configurations tested and approved by EMVCo

1. Once an application kernel has been approved, minor changes, as described in TAWG Bulletin 11, may be changed without impact to the original approval

2. Once an application kernel has been approved, major functional options, as described in TAWG Bulletin 11, cannot be changed without requiring retesting by an EMVCo laboratory.

2.6 Split Application Kernel testing In recognition that new type of devices are designed such as Cloud based solution or Merchant Server Solution and therefore application kernels are split over multiple devices, EMVCo has revised its type approval testing process to accommodate Split Application Kernel test submission.

ICS Identification of the various sub components of the Split Application Kernel and its location within the devices is the most crucial part of the Split Kernel submission.

All parts of the Split Application Kernel and the devices supporting these parts shall be clearly referenced in section IIa of the ICS with for each parts its checksum.

As for the other kernels (non split kernel), the devices needed for the solution but which are transparent shall be described (such as transparent PIN pad, transparent mobile, etc) in the ICS in the appropriate section.

Each checksum value shall be easily retrievable from each sub component for verification purpose during type approval (as per Appendix B rules.

As each part of the Split Application Kernel as its own checksum, an overall kernel checksum is not required.

Test Report provided by the Laboratory shall contain a clear technical description of the solution containing the split application kernel:

• All device/components and their relationship,

• Preferably with a figure of the solution,

2.6.1 Resubmission – Sub Component Change Process In case the vendor would like to change physically one of the sub components containing a part of the split kernel, resubmission of the whole device will be required.

The following rules will be applied to approve application kernels, submitted to EMVCo for testing as result of changing a sub component in the device:

• The changed sub component is identified in the ICS submitted

• The whole device with changed physical sub component is tested by the Laboratory with Regression template,

• Newly submitted device will also be retained by the laboratory for a period of the LoA validity + 1 year

Note 1: this process applies only if the split application kernel is strictly identical (same version, same checksum of all modules) to the initial one.



Note 2: PPCP is an example of Sub Component Change Process

2.6.2 Case of change of a transparent sub component In case the split application kernel is used with a transparent sub component (no EMV functions on board, no encryption on board), such as a transparent PIN Pad, ECR or Mobile, the Initial submission of the Application Split Kernel shall be done with this transparent device present and referenced (standard submission). If the Product Provider wants to change this transparent device, as it is transparent, no testing is required.

2.7 Application Kernel testing with multiple PIN Pad Support

In recognition that many application kernels are developed to function with multiple PIN Pad peripheral devices, EMVCo has revised its type approval testing process to accommodate multiple PIN Pads during a single test submission.

Unless explicitly stated otherwise, all rules governing the testing of additional PIN pads apply to products submitted for Renewal testing.

Application Kernel developed were part of the EMV functions are located in the PIN Pad are considered as split kernel.

2.7.1 PIN Pad and Application Kernel relationship - Prerequisites Testing and approval of application kernels with multiple PIN Pads poses challenges to the application logic responsible for processing an EMV transaction. Traditionally the application kernel can be shared, to varying degrees, between the application kernel and PIN Pad device. In instances where an application kernel is designed to function with multiple PIN Pads, EMVCo requires that application logic be clearly partitioned between the components, and the application kernel logic associated with the PIN Pad itself be limited to PIN processing only. The clear and consistent partitioning of the application logic will allow for the application kernel to be functionally tested with what should be functionally interchangeable PIN Pads.

2.7.2 PIN Pad Change Process- Additional Prerequisites In addition to those prerequisites previously defined, the following restrictions are applied to when requesting type approval with the PIN Pad change process:

• There is no limit to the number of PIN Pads that can be submitted for approval with an application kernel

• A unique checksum must be generated and recoverable for the application kernel part located in each PIN Pad, this is in addition to the checksum required for the application kernel located in the Terminal device. The PIN Pad checksum is derived from the application logic associated with PIN processing only, but is identical in all other respects to the checksum requirements previously stated. This checksum value shall be retrievable from the PIN Pad, and will vary for each PIN Pad. Note: adding an additional PIN Pad will have no effect upon the primary checksum used to identify the application kernel.

• The application kernel code residing within the PIN Pad shall only relate to PIN functionality (offline enciphered, offline plaintext, GET DATA, etc.). No other EMV



functional portions of the kernel may reside within the PIN Pad for this process to apply.

• All PIN Pads supported by a specific kernel must perform the same functions in a consistent and interchangeable manner (offline enciphered, offline plaintext, GET DATA, etc.).

• In the case of Renewal testing, the initial kernel/ PIN Pad combination will undergo full delta testing. Additional PIN pads will be tested for any PIN functionality that has been introduced since the previous test cycle.

EMVCo recognizes that additional software may exist in the terminal or PIN Pad to allow connectivity. Such software or drivers residing in the terminal and/or PIN Pad are to exist outside the EMV Kernel. Updates to drivers or adding new drivers are to have no impact on the EMV Kernel or checksum within the terminal or PIN Pad.

2.7.3 Initial submission - PIN Pad Change Process The following rules will be applied to application kernels initially submitted to EMVCo for approval:

• At the time an application kernel is submitted for testing, the vendor shall define a baseline PIN Pad. The baseline device should be the most commonly used PIN Pad and will be subjected to the full suite of level 2 test cases.

• For each subsequent PIN Pad used with the application kernel after the initial baseline test, all appropriate PIN tests will be performed, as PIN functionality will be treated as 'newly activated code' for each PIN Pad. In addition, each additional PIN Pad will be subjected to a series of regression tests

• In the case of products being submitted for Renewal testing, the baseline will be required to undergo full delta testing. Additional PIN Pads will only be tested for new PIN pad functionality, if it has been introduced.

• All approved application kernels and PIN Pads will be retained by the laboratory for a period of the LoA validity + 1 year

2.7.4 Resubmission –PIN Pad Change Process The following rules will be applied to approve application kernels, submitted to EMVCo for testing of additional (add-on) PIN Pads:

• Application kernels approved prior to the effective date of EMVCo’s testing policy regarding PIN Pad support are excluded from resubmission testing for additional PIN Pads

• While additional PIN Pads may be supplied to a laboratory for subsequent testing and approval, testing must be performed using the application kernel physically present at the laboratory. If changes must be made to the application kernel to accommodate a new PIN Pad mode, it is considered a new application kernel that must be fully retested

• A similar method of failure analysis will be applied to the PIN Pad change process as used with the Configurable Kernel process. However, should one PIN Pad fail testing and it is subsequently determined to have no impact upon other PIN Pads, or the kernel, the application is not excluded from being further tested for resubmission with additional PIN Pads nor tested for Renewal .



• Newly submitted and approved PIN Pads will also be retained by the laboratory for a period of the LoA validity + 1 year

2.7.5 Case of single External PIN Pad In case the application kernel is used with a single External PIN Pad (no multiple PIN Pads support), this single external PIN pad shall be referenced in the ICS.

2.7.6 Case of Internal PIN Pad An Internal PIN Pad means that the PIN Pad software is part of the Application Kernel Software. Internal PIN Pad is considered for device where the Terminal and the PIN Pad are in the same hardware.

The following rules will be applied to application kernels containing Internal PIN Pad, initially submitted to EMVCo for approval:

• At the time an application kernel is submitted for testing, the Internal PIN Pad shall be present in the Application kernel and will be subjected to the full suite of level 2 test cases.

• Internal PIN Pad cannot be added later on in an Application Kernel (only at Initial Submission of the kernel).

• Internal PIN Pad can be submitted at the same time as external PIN Pad, but both shall be submitted during initial submission. It is considered as a multiple PIN Pad process (at least two PIN Pad, the internal and at least one external).

• If an initial submission is performed with an Internal PIN Pad only, no External PIN Pad can be added during subsequent submissions.

• In the case of products being submitted for Renewal testing, the PIN Pad will be required to undergo full delta testing.

• All approved application kernels will be retained by the laboratory for a period of the LoA validity + 1 year

2.7.7 Case of PIN Pad without EMV function on board (transparent PIN Pad) In case the application kernel is used with a transparent PIN Pad, the Initial submission of the Application Kernel shall be done with the external PIN pad present and referenced (standard submission).

Transparent PIN Pad means that the following functions are possible, but not limited to:

• Receives and sends APDU,

• Display info received, and displayed to the cardholder/merchant

• Captures key entered,

• Encryption of message to the POS (or connected device)

• Online PIN block Encryption

No EMVCo Application kernel functions are on board such as:



o Offline PIN verification,

o Offline PIN Encryption,

When a Product Provider submits an Application kernel with a transparent PIN Pad, a document explaining the PIN Pad Architecture and transparency shall be provided to the Laboratory which shall verify that the PIN Pad comply to the above rules. This document shall be part of the test report.

If the Product Provider want to change the PIN Pad, as the PIN Pad is transparent, Multiple PIN Pad change process is not required (It is not necessary to test the additional PIN Pads).

2.8 Merging Configurable kernel process and Multiple PIN Pad process

Unless explicitly stated otherwise, all rules governing the testing of the merging of configurable kernels and PIN Pads apply to products submitted for Renewal testing.

2.8.1 Prerequisites EMVCo previously did not allow the combined usage of the Configurable Kernel process and the Multiple PIN Pad process. EMVCo’s process is updated to allow vendors to take advantage of both processes at the same time. In order to test to this process, vendors are required to adhere to all requirements as defined under the Configurable Kernel process (Section 4.4) and the Multiple PIN Pad process (Section 4.5).

It should be noted that vendors with previously approved Configurable Kernels or kernel supporting Multiple PIN Pads maybe able to utilize this process for subsequent submissions under the following conditions:

• For approved Configurable Kernels that are also capable of supporting multiple PIN Pads

o The kernel must have been already portioned with only the PIN functionality isolated within the PIN Pad

o The portion of the kernel residing within the PIN Pad must have a checksum

• For kernels approved with Multiple PIN Pads that are also configurable

o The kernel must have had all configurable functions identified on the ICS

o The kernel must have a checksum

o The configurable functions must have a checksum

2.8.2 Initial submission All rules defined for an initial submission for the Configurable Kernel process (Section 4.4) and the Multiple PIN Pad process (Section 4.5) are applicable.

A full suite of level 2 test cases will be applied to the defined baseline configuration and baseline PIN Pad. All additional PIN Pads will be PIN regression tested with all defined configurations run PIN Pad regression testing

2.8.3 Resubmission All rules defined for a resubmission for the Configurable Kernel process (Section 4.4) and



the Multiple PIN Pad process (Section 4.5) are applicable.

2.8.4 General rule All PIN Pads submitted for the combined configurable kernel and PIN Pad change process will be tested with all defined configurations.

2.9 Application Kernel testing with multiple Operating system Support

Traditionally, EMVCo has considered porting approved kernel software onto a different operating system as a major change, requiring resubmission for full Type Approval. EMVCo now accepts kernels that are capable of operating with different or modified Operating Systems to receive regression testing for EMVCo type approval.

Unless explicitly stated otherwise, all rules governing the testing of multiple OS apply to products submitted for Renewal testing.

2.9.1 Prerequisites It should be noted that vendors with previously approved Static kernels, Configurable Kernels or kernels supporting Multiple PIN Pads may utilize this process for new or modified Operating Systems.

For this process to apply:

• The Operating System shall be fully interchangeable, no recompilation or linkage for the kernel code is allowed

• The kernel checksum and/or PIN pad checksum shall not change based on the Operating System modification

• The set of functions within the kernel must not change when residing on different operating systems

2.9.2 Initial submission The first defined operating system will become the baseline operating system. All rules defined for an initial submission for the Configurable Kernel process (Section 4.4) and the Multiple PIN Pad process (Section 4.5) are applicable.

For all additional operating systems defined in the initial submission, The OS report Template of the level 2 test cases (representing approx. 40% of the test cases) will be applied for the baseline kernel configuration and the baseline PIN Pad if present. All other defined kernel configurations, with the baseline PIN Pad if present, will receive regression testing for each additional operating system defined: the 2CS series and 2CT series together with the applicable tests for options enabled or disabled for the first time. All PIN Pads in combination with the baseline kernel configuration will receive PIN Pad regression testing for each additionally defined operating system.

If an error is encountered during this process, then the following will apply:

• The new operating system will not be approved for any configuration or any PIN Pad. After correcting the issue, the vendor may submit his kernel with the new operating system as a new baseline kernel for type approval testing.

• If the error is encountered in a subsequent configuration the vendor may choose to



discard the configuration for all operating systems, and keep the new operating system approval for all remaining configurations.

• If an error is encountered in a subsequent PIN Pad, the vendor may completely remove this PIN Pad from all operating systems, or may repair and retest the PIN pad against all operating systems with their baseline configuration.

2.9.3 Resubmission There is no limit to the number of Operating Systems that may be resubmitted for type approval testing - one or more Operating Systems may be identified. For each additional operating system defined in a resubmission, the same testing rules concerning regression testing and failure analysis apply (Section 4.7.2).

All rules defined for a resubmission for the Configurable Kernel process (Section 4.4) and the Multiple PIN Pad process (Section 4.5) are applicable.

2.10 Application Kernel with Platform Dependencies: Multiple Platform submission

According to section 4.3.3, in some integrated configurations, the EMV application kernel is platform dependent and not portable to any other terminal platforms. This portability limitation of the EMV Application Kernel will be mentioned on the Letter of Approval

For some identified cases where some EMV functions are dependent of specific Hardware, Product Provider may have several Platform with the same dependencies were the Application Kernel can be run without any recompilation.

For example Random are generated by a specific chipset (and not by the Application Kernel Software), and a second chipset, with same API, runs also the functions without any Application Kernel changes (no recompilation needed). Due to the limitation of the LoA, the support of the second chipset is not not possible without retesting of the Application Kernel in the second terminal.

To reduce the amount of retesting of the Application Kernel when multiple chispet/terminal EMVCo has revised its type approval testing process to a specific process to submit multiple Terminal with the same Hardware dependencies, in a single of multiple submission.

This process applies for same or new terminal having the same characteristics as the initial terminal (same OS, same API, etc) but with a second chipset for the the following implemented dependencies:

• 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).

2.10.1 Initial submission • Initial Submission is performed as a standard submission, without any change in the

process. The Application Kernel is submitted in only one Terminal having the Hardware dependency.



2.10.2 Resubmission – New Terminal with the same platform dependencies The resubmission of the same Application Kernel is performed with the following change:

• An ICS is provided containing the following information:

o Section IIa and V completed with the same information as the initial submission, except for the following changes:

• A new ‘Terminal Name’ for the ‘as tested in’ (page 3 of the ICS)

• Or a new Hardware description containing the Cryptographic or Random functions (page 13 of the ICS)

o Section IIb empty (even if it was filled in initial submission)

o Section VI empty (even if it was not filled in initial submission)

• The applicable fees are identical to the additional configuration fees for each supported configurations (including baseline).

• The testing performed by the laboratory on each configuration and on each additional OS will use the specific template for either:

o Random Template,

o Cryptographic Template

• The new sample loaded with the exactly same Application kernel as the one of the initial submission shall be provided by the Product Provider to the Laboratory following the standard samples rules.

• The LoA will be updated with the additional ‘as tested in’ Device information and keeping the same expiration date as initial one.

2.11 Application Kernel testing summary

2.11.1 EMVCo terminal type approval testing structure With the aid of a matrix it will be easier to determine exactly which tests will have to be run for testing additional operating systems. For clarity this is illustrated with examples below.

Please note that all rules as defined in the previous paragraphs for a configurable kernel, for the PIN Pad Change Process and the Multi Operating System Process still apply.

Session 1 – Initial submission of a Configurable Kernel with 3 PIN Pads

Assume that the vendor submits a configurable kernel with 3 configurations and 3 PIN Pads in a first test session. Then, as usual the following combinations will need to be tested using the first defined operating system (OS1)



OS1 Configuration 1 (=baseline) or static kernel

Configuration 2 Configuration 3

PIN Pad 1

Full Baseline template

Template A, including

functions added or removed for

this configuration

Template B, including


this configuration

PIN Pad 2

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad 3

PIN Pad Template

PIN Pad Template

PIN Pad Template

In the report, EMVCo expects to receive all the following test results, tested with OS1

PIN PAD 1 tested with CONFIGURATION 1: baseline template results

PIN PAD 1 tested with CONFIGURATION 2: template A results, including functions

added/removed for this configuration

PIN PAD 1 tested with CONFIGURATION 3: template B results, including functions

added/removed for this configuration

PIN PAD 2 tested with CONFIGURATION 1: PIN Pad template results






Session 2 – Additional Operating System

In a subsequent test session the vendor submits an additional operating system 2 (OS2). EMVCo then expects to receive the following test results in the new report, tested with OS2:

PIN PAD 1 tested with CONFIGURATION 1: OS report template results

PIN PAD 1 tested with CONFIGURATION 2: functions added or removed for this configuration + 2CS series + 2CT series(with 6 AIDs as per baseline report template)



PIN PAD 1 tested with CONFIGURATION 3: functions added or removed for this

configuration + 2CS series + 2CT series

(with 6 AIDs as per baseline report template)



OS2 Configuration 1

(=baseline) or static kernel

Configuration 2 Configuration 3

PIN Pad 1

OS template

Functions added or removed for

this configuration + 2CS series +2CT series


this configuration + 2CS series +

2CT series

PIN Pad 2

PIN Pad Template

- -

PIN Pad 3

PIN Pad Template

- -

Session 3 – Additional Configurations and/ or PIN Pads

Now the vendor has already defined and tested 2 operating systems. Additional configurations or PIN Pads will then need to be tested for both these defined operating systems.

If, in a third session the vendor submits an additional configuration and an additional PIN Pad, EMVCo expects to receive the following results in the new report:



Tested with the first operating system OS 1: PIN PAD 1 tested with CONFIGURATION 4: template C results, including

functions added/removed for this configuration

PIN PAD 2 tested with CONFIGURATION 4: PIN Pad template results PIN PAD 3 tested with CONFIGURATION 4: PIN Pad template results PIN PAD 4 tested with CONFIGURATION 1: PIN Pad template results PIN PAD 4 tested with CONFIGURATION 2: PIN Pad template results PIN PAD 4 tested with CONFIGURATION 3: PIN Pad template results PIN PAD 4 tested with CONFIGURATION 4: PIN Pad template results

Tested with the second operating system OS 2: PIN PAD 1 tested with CONFIGURATION 4: functions added or removed for this configuration

+ 2CS series + 2CT series (with 6 AIDs as per baseline report template)


OS1 Configuration 1 Configuration 2 Configuration 3 Configuration 4

PIN Pad 1

Baseline template

Template A, including


this configuration

Template B, including


this configuration

Template C, including


this configuration

PIN Pad 2

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad 3

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad 4

PIN Pad Template

PIN Pad Template

PIN Pad Template

PIN Pad Template



OS2 Configuration 1 Configuration 2 Configuration 3 Configuration 4

PIN Pad 1

OS template



2CT series



2CT series



2CT series

PIN Pad 2

PIN Pad Template

-

-

-

PIN Pad 3

PIN Pad Template

-

-

-

PIN Pad 4

PIN Pad

Template

-

-

-

2.11.1 Templates usage For Product submitted with multiple configurations, Laboratory shall use a different template (A to E) for each configuration. In case more than 5 configurations are submitted, the same template A to E shall be used again.

All test cases of a template x selected shall be run (if applicable based on the Terminal Options), whatever these tests will be run again on other Configurations or OS or PIN Pad with other or same templates.

Activated Options (or Deactivated Options) difference between the Baseline Configuration and the additional configuration under test, shall be taken into account for the additional test cases to be run (the difference is always between the Baseline Configuration as reference and the Additional Configuration under test).



2.12 ICS Submission rules

2.12.1 ICS Submission • The initial ICS submission to the EMVCo is free of charge.

• The ICS submitted must be the ICS in pdf format, capable of importing/exporting XML format and shall be digitally signed by the Product Provider and the Laboratory at the time of submission to EMVCo.

• The Laboratory supplies the signed copy of the vendor-supplied ICS to EMVCo for review prior to the start of the type approval testing process.

• EMVCo will review and approve the ICS by returning the ICS in pdf digitally signed and with the official ICS number.

• In case the ICS is incorrectly filled, decline fee applies to Laboratory.

2.12.2 ICS replacement • One free ICS replacement is allowed during the ICS life cycle. ICS replacement fee

will be charged (to the Product Provider) for any subsequent ICS replacement request.

o Same submission process applies as for initial ICS submission (Laboratory submits the changed ICS).

o This applies to any change in the ICS after the official approval of the ICS by EMVCo.

• After the start of the test session of the Product, ICS replacements (following the rules of the previous bullet) are only allowed for administrative information update (such as name of product) but are not allowed for technical information update.

• Laboratory shall ensure that any ICS change requested is not made to hide a bug in the product (such as deactivation a function because this function is not working properly).

• ICS replacement is no more allowed after Test Report submission to EMVCo.

Note: ICS decline process remains and any error reported by EMVCo will be charged to the Laboratory (as Laboratory is responsible of reviewing the ICS provided by the Product Provider). ICS decline process applies to the initial ICS submission and also to any other ICS replacement (charged or not charged to the Product Provider).



2.13 EMVCo terminal type approval fee structure Fees are subject to change but accurate at the time of publication

EMVCo will apply an administrative fee for the first baseline configuration with baseline PIN Pad if present, in combination with the first operating system, and an additional fee per additional PIN Pad and per subsequent kernel configuration and per additional ‘as tested in’ Terminal (according to section 4.9). Per additional operating system to be evaluated, a fee of will be charged.

An administration fee will be applied to any product being submitted for Renewal or Restricted Renewal testing. This fee includes testing of subsequent configurations and additional PIN Pads.

Approval Process apply fees for the following:

• Baseline Submission, one OS (with Baseline PIN Pad if present)

• Each Additional Config or PIN Pad

• Each Additional OS

• Renewal (or restricted) including additional config/PIN Pad/OS

• ICS Replacement (starting at 2nd Replacement)

• Declined ICS/Report

• LoA reissuance/duplication

Note: The amount of each fees are published in Terminal Type Approval Bulletin 185.

The fee structure can be presented in a graph as follows.

For the first operating system OS1:

OS1 Configuration 1


Configuration 2 Configuration 3 Configuration x

PIN Pad 1 (=baseline) or no PIN Pad defined

Baseline Submission

fee

Additional Config fee



PIN Pad 2 (if baseline PIN Pad was defined)

Additional PINPad fee

- - -



- - -

PIN Pad x (if baseline PIN Pad was defined)


- - -



For each additional operating system OSx:

OSx Configuration 1


Configuration 2 Configuration 3 Configuration x

PIN Pad 1 (=baseline) or no PIN Pad defined

Additional OS fee

- - -


- - - -


- - - -

PIN Pad x (if baseline PIN Pad was defined)

- - - -

Administrative fees are subject to change without notice.



2.14 Integrated Point of Sale An integrated Point of Sale configuration can present a challenge for EMVCo testing at a laboratory. To circumvent the necessity of transporting all the various components or peripheral equipment to the laboratory, the majority of integrated point of sale devices can be tested in a laboratory with application provider supplying emulators to replicate the supplementary devices as needed. Emulator use is acceptable in the test environment as long as these devices do not affect the EMV application interaction between the card the terminal. Examples include:

• The EMV device and application receives information from the cash register regarding the transaction amount. In this case, the cash register is simply taking on the role of an interface requiring the manual amount entry into the device resulting in no impact on the functionality being tested.

• If the EMV device uses a transport mechanism from the cash register to communicate with the store controller, merchant host or the acquirer network, the mechanism is merely a conduit for passing the information to the appropriate entity. Any function or part of a function that is not performed over the card/terminal interface is considered to be outside of scope for EMV Level 2 testing and approval process.

Since the auxiliary equipment components have no direct performance affect or impact on the EMV application card-to-terminal interface, they can be emulated for testing.



3 Roles & Responsibilities The following sections define the roles and responsibilities of the various participants in the type approval process.

3.1 EMVCo EMVCo defines the requirements for an EMV Terminal and Type Approval requirements. EMVCo manages the Card Type Approval Secretariat and the Security Evaluation Secretariat.

For Terminal Products EMVCo provides the following services:

• Owns, defines, and maintains the EMV Specifications and Type Approval requirements

• Owns, defines, and maintains the EMV security requirements

• Defines auditor qualification requirements

• Defines laboratory accreditation requirements

• Owns, defines, and maintains Test Cases appropriate to test that Products conform to EMV Specifications and Type Approval requirements

• Owns, defines, and maintains procedures used to perform Level 1 testing

• Owns, defines, and maintains procedures used to perform Level 2 testing

• Defines test tool qualification requirements for EMVCo defined Test Cases

For more information, please refer on EMVCo’s public website to the Terminal Type Approval and Security Evaluation sections.

3.2 EMVCo Type Approval Secretariat (CATA) The Card And Terminal Approval Secretariat (CATA) manages the Terminal Type Approval process. This includes the administrative functions associated with Providers registration, completion of contracts, processing approval requests and fees, issuing letters of approval or rejection, etc. The Type Approval Secretariat:

• Coordinates with the Payment Systems

• Evaluates auditors and determines whether EMVCo qualification should be granted to an auditor

• Manages the auditor appeals process and resolves qualification disputes

• Evaluates laboratory audit results and determines whether EMVCo accreditation should be granted to a laboratory

• Manages the laboratory appeals process and resolves accreditation disputes

• Evaluates a Product Implementation Conformance Statements (ICS), and communicates evaluation results



• Evaluates Product Requests for Approval, and communicates evaluation results

• Evaluates renewal requests

• Evaluates appropriate resolution of Product issues reported to EMVCo, including additional testing or revocation of Letter of Compliance for a particular approved Product

The role also includes communicating Type Approval status to third parties, maintenance of Type Approval information on the EMVCo website, and the maintenance of a database that provides the following:

• List of EMVCo Qualified Auditors

• List of EMVCo Accredited Laboratories for functional evaluation (Level 2)

• Type Approval documentation and forms

• List of EMVCo Test Tools

• List of EMVCo approved Products

3.3 Auditors Two types of auditors are required for contactless process:

• Laboratory Auditor: The Laboratory Auditor is in charge of auditing the Laboratory for accreditation purpose.

• Compliance Auditor: The Compliance Auditor is in charge of auditing the reports in case of restricted renewal process.

3.4 EMVCo Accredited Laboratories An EMVCo Accredited Laboratory is a test facility that has been audited by an EMVCo Qualified Auditor and accredited by EMVCo to conduct testing for Type Approval of Products in accordance with EMVCo’s Type Approval requirements and Test Cases. The laboratory must:

• Apply to EMVCo for accreditation

• Conduct testing in accordance with EMVCo’s Type Approval requirements and with EMVCo Test Tools

• Validate that the Implementation Conformance Statement (ICS) is complete and all sections and fields are consistent

• Send the ICS to EMVCo on behalf of Product Provider

• Begin testing a product only after receiving EMVCo’s acceptance of the Product’s ICS

• Inform the CATA Type Approval Secretariat whenever testing is terminated prior to completion of all tests

• Ensure that, if any modification is made to the Product during the test session, a new test session is initiated and a new ICS is accepted by EMVCo



• Identify in the test report the reason for any modification

• Identify in the test report any discrepancy found during the test session, either failure of a test or non-conformance to the specification

• Issue test reports in an electronic format as defined by EMVCo

• Be able to conduct testing for all Test Cases and options defined by EMVCo for the evaluations

• Maintain test reports, test logs, and product samples

• Provide a quarterly report of testing activities and performance to EMVCo

• Maintain EMVCo accreditation

• Apply for renewal of accreditation every four years

• Notify EMVCo of any change in contact information

It is the responsibility of the laboratory to ensure that its staff members are properly trained on test tools and EMV Specifications. It is not the responsibility of EMVCo to provide training.

Payment of fees for testing tasks undertaken by EMVCo Accredited Laboratories is the responsibility of the entity requesting EMVCo’s approval. EMVCo is not responsible for laboratory testing fees.



4 Type Approval Procedures The type approval procedure followed by application providers, laboratories, and EMVCo includes the following:

• Application provider obtains registration information from the EMVCo web site or from an EMVCo accredited laboratory

• Application provider submits a completed registration template to the EMVCo Type Approval Secretariat

• Application provider obtains the Level 2 EMVCo/vendor contract from EMVCo, the EMVCo web site or from an EMVCo accredited laboratory.

• Application Providers conclude the contract with EMVCo. A contract between EMVCo and the Product Providers must be signed before test results are submitted to EMVCo for evaluation and potential type approval.

• Application provider selects a Level 2 laboratory from the list of accredited facilities published on the EMVCo web site.

• Application provider concludes a contract with the accredited laboratory in respect of the EMV application kernel to be tested and the number of configurations that will be supported by that kernel

• The Laboratory reviews for accuracy the ICS received from the Application Provider and then archived for later comparison. Laboratory submits a validated copy of the completed ICS to EMVCo prior performing testing. This ICS must be in pdf format, capable of importing/exporting XML format and shall be digitally signed by the Application Provider and by the Laboratory (both signatures on the same ICS submitted) as paper copy or scanned copy are no more accepted..

• The EMVCo CATA Secretariat will assess the ICS validity.

o If the submitted ICS is acceptable the Secretariat responds back to the Laboratory and return as the same time the approved ICS in pdf format digitally signed.

o If the submitted ICS is unacceptable the Secretariat inform the Laboratory and apply the “Decline fees" (see Bulletin)

Note: An Approved ICS is valid 6 month. If the related request for Approval is not submitted and the invoice is not paid within that period, all related documents to this approval request are no more valid (ICS, RFA, report) and a new process shall be restarted. Note that in this case the invoice is not be reimbursed.

Note: If the test session has not started yet and the ICS already been approved, when a new EMVCo release of the ICS is published, then the ICS shall be resubmitted with new latest ICS version before laboratory can submit the report.

§ Once ICS has been validated by the Secretariat, the Laboratory performs testing of the submitted EMV application kernel against the published Level 2 test requirements and test cases

§ Application provider submits a completed Request for Approval form to EMVCo. Based on the Request for Approval form EMVCo will provide Application provider with an invoice.

§ Based on the received invoice Application provider pays the administrative fees to EMVCo.



§ On Application provider’s request, the laboratory submits the (with checksum) and test results for all kernel configurations tested to the EMVCo Type Approval Secretariat.

§ If fee payment is confirmed by EMVCo Finance Secretariat, analysis of the ICS and test results by EMVCo and, if appropriate approval notification

o Type approved EMV application kernels are posted on the EMVCo web site after approval notification

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



Figure 5.1: Application Kernel Type approval Procedure



4.1 Registration Registration provides the vendor with entry into the EMVCo approval process in order to make the application provider aware of all formalities that need to be finalized prior to submitting their final test report to EMVCo for approval.

The registration process is composed of the following steps:

§ The application provider submits a registration request to the EMVCo Type Approval Secretariat.

§ Registration request document shall be send to the EMVCo Type Approval Secretariat in pdf format (unlocked to ensure that copy and paste of information are possible) electronically signed. Scanned copies are not allowed.

§ The EMVCo Type Approval Secretariat will send to the vendor a response with the following:

o Registration reference number

o Contract between EMVCo and application provider

o Appropriate contact information

o Administrative fees charged for administrative fees associated with type approval and payment instructions

4.1.1 Contract with EMVCo The application provider must complete and sign the EMVCo defined contract before final test results are submitted to EMVCo for evaluation and possible approval. This contract governs the relationship between EMVCo and the application provider and includes the application provider’s acceptance of all specifications, procedures, terms and conditions governing EMVCo Level 2 Type Approval.

The EMVCo contract is available on EMVCo web site for download.

The contract is standard for all application providers to ensure consistent requirements for all participants. Contract customization for individual application providers is not possible.

4.2 Application Provider and Laboratory Operations The following operations are performed by the application provider and the laboratory as they relate to the type approval procedure:

§ The application provider is free to select any EMVCo accredited laboratory for the purpose of achieving EMVCo type approval. A list of accredited laboratories is published on the EMVCo web site. Once a laboratory is selected, the application provider and laboratory execute a contract defining the individual rights and obligations of the contracting parties. The provisions of application provider/laboratory contract are up to the contracting entities and entirely out of EMVCo’s scope. Any fees payable to the laboratory in respect of the tests to be conducted are solely at the discretion of the laboratory.



§ Application provider sends an Implementation Conformance Statement (ICS) to the chosen laboratory for each implementation under test (IUT) that it submits. The ICS format and content requirements are determined by EMVCo. The ICS submitted must be the ICS in pdf format, and shall be digitally signed by the Application Provider at the time of submission to EMVCo.

o The ICS submitted to the laboratory by the vendor may identify one or more configurations that will be tested for the kernel. There is no effective limit to the number of configurations that can be identified and submitted for testing. If multiple configurations are being submitted for approval, the application provider may identify one configuration as the “baseline” application. If the application provider does not identify a baseline application, the configuration with the most options enabled will be selected as the default baseline.

o The ICS submitted to laboratory by the vendor for multiple configurable kernels must identify all configurable options – even if these options are not active for any of the fixed configurations that are being submitted for testing and approval.

§ The laboratory supplies a copy of the vendor-supplied ICS to EMVCo for review prior to the start of the type approval testing process, digitally signed by the Application Vendor and by the Laboratory.

§ The laboratory tests the application kernel in accordance with EMVCo test procedures.

§ Testing shall be performed in Laboratory premises with the complete solution samples located in these premises.

§ The laboratory verify the checksum values of:

o the Applications Kernel,

o each configurations of the Kernel submitted (if applicable),

o each PIN Pad (if applicable),

o each sub modules or external libraries used for the application kernel,

To do this the Laboratory shall retrieve from the Terminal sample all checksums and compares against values declared by the Application Provider in the ICS.

§ The application provider prepares the Request For Approval form and submits it to EMVCo. EMVCo can then issue the invoice for the application provider. RFA can be send only after the ICS has been approved by EMVCo.

§ Application provider submits payment to EMVCo based on the received invoice. The amount of payment will depend upon the number of configurations that are being submitted for approval.

§ The laboratory sends the final test report to the application provider being the owner of the test results. The laboratory must advise EMVCo of any failures that have been encountered in any configuration(s) during testing.

• The laboratory submits an original copy of the test results report to EMVCo, and ensures application provider has already submitted his completed Request For Approval form.

4.2.1 Contracts between Laboratories and Vendors The provisions of the contract entered into between laboratories and application providers are entirely outside of EMVCo’s scope. However, the likely areas for inclusion are mentioned below for information purposes only:



§ Any laboratory requirements needed for testing including any software application required interfacing with the laboratory test equipment, e.g., host emulator, etc.

§ Reference to the contract between the application provider and EMVCo

§ Agreement of mutual cooperation in providing information and assistance where needed

§ Lead-time for the execution of the type approval tests

§ The number of samples available for testing.

§ Arrangement for the preparation and delivery of samples

§ Right to keep all samples

§ Recognition that no infringement on the independence or impartiality of the testing laboratory will be allowed during or after testing

§ Agreement on the boundaries of use of the test report

§ Provisions for conflict resolution

4.2.2 Type Approval Test Report The results of the level 2 type approval tests are combined in one signed test report that is submitted to EMVCo in electronic format for review. The test report must include the following information:

• Identification of the laboratory

• Identification of application provider

• Identification of EMV application kernel

• Identification of hardware (i.e., terminal platform) on which the application will run

• Identification of the Implementation Conformance Statement

• EMVCo specification/test case version used for test

• Identification of all laboratory test equipment and software versions used during the tests

• A technical description of the solution under test (all components, relationship, preferably with a figure or a picture).

• Dates test were performed

• If vendor is submitting a test report with areas they recognize has non-conformance for an approval with conditions, the vendor needs to describe these area’s along with the rationale as to why these non-conformance would not affect interoperability as well as a proposed plan to resolve the issues

• If multiple configurations have been tested by a laboratory and an testing error occurred in one of the non-baseline configurations, the application provider may:

o Submit only baseline configuration for approval

o Request approval of all configurations in which no testing errors were encountered. However, the application provider should be aware that additional testing analysis under the direction of EMVCo would be necessary and will likely result in additional testing costs that must be incurred by the application provider. Note: if errors are encountered while testing a multiple configurable kernel, that



kernel may not be resubmitted for testing for any additional (add-on) configurations.

• For all configurations, the test case execution results for each test case:

o EMVCo defined test case number and title

o Pass, Fail, or Not Applicable test result

o For Not Applicable designated test case results, an explanation justifying this designation

o Additional laboratory comments, if appropriate

• A detailed description from the test laboratory of failed tests including logs of the test results for each reported discrepancy in the failed test.

• A detailed description of any exception test(s) performed or equipment utilized and a description of related test results

• A detailed description of the application provider’s modifications that may be required for the purpose of successfully executing the EMVCo test cases.

4.2.3 Samples Management Product Provider shall provide to Laboratory the physical samples needed for testing in Laboratory purposes under the following rules:

§ One sample including all necessary Hardware (PC, Terminal, IFM, PIN Pad, Mobile phone, etc).

§ Right to keep all approved samples for a period of the LoA validity + 1 year. Note: samples are retained for subsequent testing purposes. The Product Provider must provide the necessary support to the laboratory to ensure the kernel remains fully functional.

If the Level 1 and Level 2 approval are performed within the same Laboratory, the same physical sample (including all hardware as listed in first bullet above) used for IFM Level 1 Approval may be used for Level 2 testing, as long as the Laboratory is able to set up this sample easily for the Level 1 (DTE) and for the Level 2 (Application Kernel), and this each time the sample is needed for testing or re-testing later on.

If a Product Provider submit multiple EMV Application Kernels, and each Kernel is using the same physical sample (including all hardware as listed in first bullet above), the same sample can be used for the approval of all Application Kernels as long as the Laboratory is able to set up this sample easily for each Level 2 (Application Kernel) and this each time the sample is needed for testing or re-testing later on.

4.2.4 Case of samples not transferrable into Laboratory premises EMVCo recognize that samples of specific devices cannot be transferred into laboratory for testing purposes. Potential concerned devices are:

- Cloud based Solution

- Merchant Server based Solution

- ATM or Petrol Station Devices

Case of Cloud based Solution or Merchant based Solution



The ICS shall be filled accordingly and one of the following testing and samples storage approach shall be applied (by preferred order):

Solution 1: The server part of the kernel is loaded into a PC simulating the physical server connected to the physical POS or other devices of the solution. In that case:

• The samples located in the Laboratory premises consist of: A PC (simulating the server) plus all other physical devices of the solution (POS, PIN Pad, Mobile, etc) including the device containing the IFM,

• Testing is performed in Laboratory premises,

• The samples described above are the one retained by the laboratory (including the PC)

Solution 2: The vendor can provide a connection (with the real protocol) from the real physical server (containing the server part of the Kernel) to the other physical devices (such as POS, PIN pad, Mobiles, etc) located in the laboratory premises.

1. The samples located in the Laboratory premises consist of: All physical devices of the solution (POS, PIN Pad, Mobile, etc) excluding the physical server.

2. The samples located at the vendor premises consist of: the physical server containing the server part of the kernel

3. Testing is performed in Laboratory premises.

4. Samples retention:

• Laboratory shall retain: all physical devices excluding the server

• Vendor shall retain: the physical server with the kernel part, exactly in the same version/environment as the day of testing.

Solution 3: If the above two options are not possible, other approach such as testing in vendor premises may be decided by EMVCo on a case by case basis.

Note: in Solution 2, if the vendor is not able to retain the physical server for the LoA validity + 1 year with the kernel part in the same state as the day of testing, at least for additional testing purpose he must be able to set up again the samples in the same stage with eventually a new OS version. Note that in that case, the renewal of the Kernel will be not possible and a full testing will be required after the LoA validity period.

Note: for Solution 2 and 3, EMVCo may request an audit of the Samples archived at Product Provider premises to ensure the appropriate storage of the samples.

Case of any ATM or Petrol Station In case that the ‘as tested in’ product device cannot physically be transferred as such in the Laboratory premises for the test session, then:

Solution 1: Vendor has to provide to the laboratory a test device (such as a PC for example) having all necessary supported components, such as key pad or PIN Pad, specific screen, IFM (including automated reader if present), kernel executing environment including real OS,



etc of the ‘as tested in’ product, even if not in the real casing to support the EMV Kernel to be tested:

• The samples located in the Laboratory premises consist of: A PC (simulating the server) plus all other physical devices of the solution (key pad, PIN Pad, Mobile, etc) including the device containing the IFM, etc

• Testing is performed in Laboratory premises,

• The samples described above are the one retained by the laboratory (including the PC)

In this case EMVCo may request an audit of the Samples archived at Product Provider premises to ensure the appropriate storage of the samples.

Solution 2: If above stated solution is not achievable, before starting any test session, Laboratory has to provide to the CATA a detailed explanation, and if EMVCo accept the constraints, Laboratory can perform the test session at Product Provider premises, under the following rules:

• The samples located in the Product Provider premises consist of the real complete device.

• Testing is performed in Product Provider premises,

• The samples shall be retained by the Product Provider for the LoA validity + 1 year in the same stage as during the test session (same OS, same HW, etc).

Note: if the vendor is not able to retain the sample for the LoA validity + 1year with the kernel part in the same state as the day of testing, at least for additional testing purpose he must be able to set up again the samples in the same stage with eventually a new OS version. Note that in that case, the renewal of the Kernel will be not possible and a full testing will be required after the LoA validity period.

Note: For Solutions 1 (Server, Cloud ATM, Petrol Station) above: Laboratory shall inform EMVCo and can start session anytime.

Note: For others Solutions (Server, Cloud ATM, Petrol Station) above: Laboratory shall inform EMVCo, before starting the test session, that testing is performed with samples present in Product Provider premises. EMVCo will give a formal acceptance within 2 weeks after the written request. If the Laboratory provides a test report without having the formal acceptance, the decline report fees will be applied to the Laboratory.



4.3 Application Provider Preparation for Approval Request

The application provider determines whether test results resulting from laboratory testing will be submitted to EMVCo for evaluation. Submitting test results to EMVCo for evaluation indicates vendor acceptance that the test results are a true representation of application performance. EMVCo will not comment in advance as to whether a testing variance will be acceptable or not. Test results may be submitted to EMVCo for evaluation up to 90 days from the date they are generated by the laboratory. Test results older than 90 days are expired and cannot be submitted for evaluation. Application re-testing is required to create a current test report if the validity period is exceeded and EMVCo evaluation is desired.

The vendor must ensure that the Implementation Under Test (IUT) associated with test results submitted to EMVCo for evaluation remain unaltered and accessible in a timely manor during the evaluation process. It is recommended that the IUT remain in the possession of the laboratory until EMVCo has approved or declined the request for approval.

4.4 Application Provider Dossier The dossier submitted to EMVCo will comprise:

• A signed copy of the Implementation Conformance Statement (ICS), received from the testing laboratory

• Letter requesting approval (Request For Approval form) received from Application Provider

• Product Provider payment • The complete and unchanged Test Report received from the testing laboratory • Any additional supporting documentation the vendor believes is appropriate

4.5 EMVCo Review and Approval Upon receiving the dossier, EMVCo will:

• Review the submitted test report and determine if type approval should be granted for one or more configurations

• Notify the application provider of type approval or denial for one or more configurations

• Issue letter of approval for one or more configurations, if appropriate

• Provide notification of EMV application kernel type approval

Terminal Level 2 LoA identifies:

�� the approved Application Kernel name, version and checksum

�� the configurations –if applicable- that have been tested and checksum(s)

�� the Terminal and PinPad names, in which it has been tested and checksum(s)



�� the Operating Systems with which it has been tested

�� the EMV Specifications version against which it was tested,

�� the Test Plan version against which it was tested,

�� the list of approval numbers for the different tested features

�� the Renewal date.

4.6 APPROVAL WITH CONDITIONS EMVCo does not grant waivers for deviations found in components developed to EMV4.0 (or higher version) specifications. However, in cases of nonconformity that do not introduce potential interoperability issues, the vendor may formally request EMVCo to modify the specifications to accommodate the deviation. In such cases, the approval could be granted pending a specification change.



4.7 Type Approval Renewal Process

4.7.1 Basic Policy

4.7.1.1 Full Renewal An Application Kernel approval is valid for 3 years. This validity period applies to static and configurable kernels. The starting date is the date of the initial baseline approval, independently from subsequent resubmission.

Every 3 years, EMVCo evaluates whether the product demonstrates sufficient conformance to the current EMV specification. If the evaluation result is positive then EMVCo gives an extension to the Application Kernel Letter of Approval.

After the Renewal date, kernels not passing Renewal testing nor applied for Renewal testing will be removed from the approved kernels list and their Letter of Approval will be considered revoked.

Six months before the Renewal date of their Application Kernel, EMVCo will send a notification letter to the vendors. After the reception of this letter and prior to the Renewal date, vendors may request their Renewal by submitting the originally approved product to EMVCo for Renewal testing

Note: Vendors are not allowed to apply for Renewal testing before receiving the notification letter

Note: When the vendor submits for Renewal an Application Kernel with Multiple Configurations, he may decide to exclude some configurations from the renewal approval.

Renewal Test Plan The set of the Renewal test will be generated based on the newly added or modified test cases since the older test plan the application kernel was tested against and the most current test plan at the time of testing. So renewal testing is the Delta testing only (difference between the test plan version). No regression testing is needed for renewal. The most current test plan reference is the version available at the time of the Type Approval test session. Two situations may occur:

- the test plan is unchanged since previous approval: the Renewal date will be extended automatically for another 3 years.

- the test plan has been updated: 6 months before the Renewal date, application providers may submit the original sample to a Test Laboratory for Renewal Testing. The objective of the Renewal testing is to ensure these products pass the most current EMVCo testing. By passing the Renewal test, the product will receive an extension to the Letter of Approval. If the products fail to pass the Renewal testing, it will be removed from the approved kernel list and their Letter of Approval will be considered revoked.



4.7.1.2 Restricted Renewal EMVCo offers a process to allow kernels to receive a Restricted Renewal if they fail full Renewal testing but pass all critical tests. Kernels which reach their Renewal date, but fail to pass full Renewal testing, can apply for a Restricted Renewal. Eligible products will be required to submit details of the Renewal test case failures to an EMVCo approved reviewer (listed on the EMVCo website) who will grade the test case failures as critical or non-critical and enter the details into an assessment report. EMVCo will then review the report to determine whether a Restricted Renewal can be granted (see figure 7 for process flow).



Fig. 5.2: Restricted renewal process flow

Kernel reaching renewal date

Apply for renewal testing?

Renewal date extended for

another 3 years

Approval revoked

Approval revoked

One time extension of 3 years granted

as a “restricted renewal”

Approval revoked

Request for restricted renewal

review?

Are the failures critical?

All tests passed? YES YES

NO

YES

NO

YES

NO

NO

Current Renewal testing involves full delta testing. The test results of the failed kernel can be submitted to a reviewer for assessment where the failed tests will be graded as critical or non-critical. For a test to be graded as non-critical, the nature of test case or the failure itself must be considered non-critical. The criteria for a non-critical failure response are:

• The erroneous behavior is not considered serious:

o The situation being tested is unlikely to ever occur (e.g. card personalization that is completely erroneous.)

o The difference between the expected results and the actual behavior is not critical to the transaction disposition

o Although the behavior of the kernel or IFM under test is incorrect, its actual behavior mitigates the error; for example, a transaction which is expected to be approved or declined offline instead, is sent online for authorization but results in a correct approval or decline.

• The online cryptogram and corresponding data is not corrupted.

• There is no significant security exposure.

Most unwarranted declines or approvals, transaction terminations, and online cryptogram failures would be considered critical.



An acceptable report would result in the kernel being assigned a Restricted Renewal and listed as such on the EMVCo website in a dedicated list. Products not passing Renewal testing will be removed from the approved products list, and their Letter of Approval will be considered revoked.

All evaluation results will be retained by EMVCo to ensure consistent assessments across kernels.

A product can receive only one extension (three years for kernels) as a Restricted Renewal. Products must always be submitted for full Renewal testing prior to consideration for Restricted Renewal.

4.7.1.3 Addition of Future Renewal Test Cases Any new kernels going through type approval, all changes, will be mandatory to be tested from the effective date of the test plan.

4.7.2 Renewal Process – Configurable Application Kernel The Renewal date for the multiple configurable kernels is the same as the baseline configuration. At the baseline Renewal testing, all previously approved subsequent configurations are subject to Renewal testing concurrently.

If the baseline configuration does not pass the Renewal test or vendor chooses not to apply for the Renewal test, the subsequent configurations will not be eligible for the Renewal test. Any subsequent configuration that fails the Renewal test will be considered as failing the Renewal testing and extension will not be granted.

Renewal Testing

- Baseline configuration: The suite of tests of the Renewal test plan applies: Delta testing.

- Subsequent configuration: The applicable tests are the delta tests of the Renewal test plan related to terminal supported options which implementation differs from the implementation of these options in the configuration baseline.

4.7.3 Renewal Process – Multiple PINPads All approved PINPads have to be renewed concurrently at the same time as the baseline PINPad. .

If the baseline PINPad does not pass the Renewal test or has not applied for the Renewal test, the subsequent PINPads will then not be eligible for the Renewal test. If the one of the subsequent PINPads fail the Renewal test, it may and may not other have impacts on other approved PINPad, this will be subject to EMVCo’s evaluation.

Renewal Test Plan

- Baseline PINPad: The suite of tests of the Renewal test plan applies: Delta testing.

- Subsequent PINPad: The applicable tests are the delta tests of the Renewal test plan which are PIN related.



4.7.4 Renewal Process – Multiple Operating System All approved Operating Systems have to be renewed concurrently at the same time as the baseline Operating System. If the baseline operating system does not pass the Renewal test or is not applied to the Renewal test, the subsequent operating systems are no longer eligible for the Renewal test. Even if one or more subsequent operating systems fail the Renewal test, that will have no impact on the baseline.

Renewal Testing

- Baseline operating system: The full suite of tests of the Renewal test plan applies: Delta testing.

- Subsequent operating systems: No testing requiredLevel 1 Renewal versus Level 2 Renewal

In a single submission for both level 1 IFM and level 2 Kernel Renewal, when a Level 1 IFM fails the Renewal testing and a Level 2 product passes the Renewal testing, the Level 1 will be considered revoked and only the Level 2 product will be renewed.

In a separate submission where If the original only a Level 1 IFM has failed the Renewal testing, the kernel vendor has to transfer the same kernel code without modification or recompilation onto a new approved and valid IFM. The OS and the checksum have to be the same as the original product. Otherwise, it’s no more eligible for the Renewal testing. So IFM of the Terminal used for testing shall have a valid LoA at the time of renewal request.

4.7.5 Labs for Renewal testing The application provider may select to have a different laboratory to perform Renewal testing. The application provider must make the necessary arrangements to have the originally approved kernel transported between laboratories. The vendor is responsible for incurring the costs associated with this transfer.

4.7.6 Samples submission Renewal testing must be performed on kernels already physically present at an EMVCo laboratory. If the kernel is no longer present or is otherwise inoperable, EMVCo may accept a replacement kernel from the vendor for testing provided they have signed a disclaimer stating that the replacement kernel is identical in all respects to the kernel originally supplied to a laboratory for testing (without modification, same checksum(s), ..). For this reason, it is essential that vendors retain an exact and unaltered copy of the application kernel originally sent to the laboratory during the initial testing phase.

4.7.7 ICS Submission If the Kernel does not support mandatory features described in the latest version of the ICS, the product is not eligible for Renewal.

ICS submitted for Renewal testing must be based on the latest version available at the time of testing and shall be digitally signed.



5 Test Version and specification Change The following sections identify the process managing type approval test changes when the specification or test cases change.

5.1 Test Changes without Specification Update and Application Note

EMVCo reserves the right to change type approval tests at any time in order to increase the accuracy and integrity of the tests versus the EMV Specification, or for any other reasons.

Figure 5.1: Example of the timing for test changes

EMVCo will inform all participants of the new tests and fix the date(s) for activation of the new tests and deactivation of the old. EMVCo may determine a time period during which either the old or new test version may be used in the type approval process (see figure 7). However, EMVCo shall not be under any obligation to permit a phase-out of old tests.

5.2 Test Changes Due to Specification Update and Application note

After a change in the EMV Specification, EMVCo will decide: • If and when the type approval tests must be changed to accommodate the new

specifications

• When to introduce the new type approval test version

• When to stop testing and Renewal with the previous type approval test version

EMVCo will inform all participants of the new tests and the date(s) of the activation of the new test version and deactivation of the old test version.

No TTA Tests Version nBeyond this Date

Release of TTA TestsVersion n+1

TTA Tests Version n+1 ApplicableDevelopment andInstallation of NewTests

Start RunningNew Tests

Today Future

TTA Tests Version n Applicable

(TTA=Terminal Type Approval)



Figure 5.2: Time line for test changes, following changes in EMV Specification

5.3 Testing applicability All EMV Level 2 kernels will be tested to the current version of the EMV Level 2 test cases. Test case applicability is defined by the date determined by EMVCo. At which time all new kernels, subsequent submissions for Configurable Kernels and/or PIN Pads submitted on or after this date will be tested to current test plan. Previous versions of the test plan may not be used and EMVCo will reject any testing performed to an old version of a test plan after the applicable date.

Beyond this date only terminals compliantto the Reference Specification Vn+1 will besupported by EMVCo.

New version of ReferenceSpecification released

Terminals compliant to old version of theRef. Spec. are supported by EMVCo

No Type Approval and compliancetests to the Ref. Spec Vn beyondthis date

New versionof TTA testsreleased

Reference Specification Vn

Ref.Spec. Vn+1

New TTA tests applicable

Development,installation ofnew tests

Start running Type Approval and compliancetests to the new Reference Specification

Today Future

TTA tests Vn Applicable



6 Application Kernel Changes EMVCo recognizes that from time to time minor changes may occur without affecting application compliance to the EMV Specification. However, EMVCo considers a major modification to be a change in an EMV application kernel that affects the compliance of the EMV application kernel to the requirements of the EMV Specification. An EMV application kernel that undergoes a major modification shall be considered a new design for which a new type approval is required.

A major change in an application kernel may generate a different behavior of the terminal with respect to the EMV Specification and the application provider’s ICS. In such cases, the modified application kernel shall be considered a new application and new testing and evaluation is required to extend type approval to the new application kernel. The original unchanged application kernel remains type approved.

A minor change in an application kernel does not generate a different behavior with respect to the specifications and ICS. In such cases, the EMV application kernel shall not require new type approval. It is the responsibility of the application provider to maintain all evidentiary documentation describing why the modification made was minor in nature and could not negatively impact the functionality of the kernel.

The EMV application kernel provider is responsible for declaring a change major or minor. This declaration shall be supported with tangible evidence (design documents, test logs, etc.). Declarations should not be submitted to EMVCo except in cases where there is uncertainty as to whether a particular modification constitutes a major or minor change. If EMVCo determines the change is major, this will be considered a new EMV application kernel that will require testing by an EMVCo laboratory. Detailed procedures relating to change management may be provided in future documentation as warranted.

Please refer to Type Approval Bulletin #11 for additional information regarding the definition of major versus minor changes, as well as to Type Approval Bulletin # 31 for functions/capabilities that can be hidden without EMVCo requires re-approval of the Application Kernel



7 Change in Contact Information The application provider shall inform the EMVCo Type Approval Secretariat if the company name, address or contact information changes, as stated in application provider registration.

Changes impacting company names may require a new contract with EMVCo. Generally, approval notification letters are not reissued when name changes are the result of corporate mergers, sales or other events covered by the “Assignment” and “Successors and Assigns” sections in the contract between application provider and EMVCo.

Modifications to company addresses and contact information will be applied to the EMVCo web site and subsequent communication (i.e. approval notification) with the application provider. Some organizations specify different contact information for various products. Contact information changes will be applied to all listed approved application kernels unless specially stated on the request.

If as a result of a company name change, address change or contact change, EMVCo needs to re-issue an existing LoA on explicit request from the application provider, EMVCo will request an administrative fee per LoA re-issuance. Please note that LoA’s are only issued electronically."



8 Appendix A: Finding the forms Application provider can find all vendor forms he needs to complete on the EMVCo website (www.emvco.com) under Terminal Type Approval, section Type Approval Vendor Forms.

- Level 2 Registration Form

- Level 2 Vendor Contract

- Level 2 Implementation Conformance Statement

- Level 2 Request for Approval

- Level 2 Request for Renewal

9 Appendix B: Checksum Rules

The Application Provider shall include in the Application Kernel, the kernel Configuration (for MCK) and the PIN pads submitted a checksum computation following the below rules:

• Each Application Kernel shall have a unique Checksum. In case of Split Application Kernel, each part of the kernel shall have a unique Checksum, and in that case no need of an overall checksum.

• Each Configuration (Baseline and each subsequent Configuration) of the Application Kernel shall have a unique Checksum,

• Each PIN Pads shall have a unique Checksum.

• The Checksum computation of the Application kernel shall include all requirements of the Kernel (such as Cryptography, EMV data management, EMV functions, etc).

• In case that the application kernel is based on several software modules (such as using external routines, Crypto librairies, etc), each software module shall have its own unique Checksum. In that case the Application Kernel Checksum can be the checksum of all software module checksum.

• The following EMV data element values shall be included in the unique Checksum of each Configuration (Baseline and each subsequent Configuration):

o Terminal Type (9F35)

o Terminal Capabilities (9F33)

o Additional Terminal Capabilities (9F40)

• Any change in a Kernel or a software module, whatever it as a major or minor change, shall generate a new unique checksum value in the changed kernel or software module.

• Application Provider shall use an algorithm that generates a unique value each time the kernel or module is changed.

• The Terminal sample shall contain a software mechanism to easily retrieve all checksum values of all Software Modules (librairies, Sub modules, Kernel, kernel



configurations, PIN Pads,…) when these Software Modules are loaded in the Terminal. When used, this software mechanism shall compute dynamically the Kernel and Kernel Configuration Checksum (not necessary for the external libraries). In case of a Split Kernel, each sub component shall follow the same same rules.

Note: Static Kernel (not MCK) shall have a Checksum for the Application Kernel and a checksum for the Static Configuration Data (to keep consistency of Checksum Approach between static and MCK Kernels).

The below figure gives an example of Checksum coverage.



Fig; 10.1: Checksum coverage example

In this example, the Full Kernel C-n functionalities are split over a software Kernel C-n Module (blue box) and 3 external librairies/modules (Yellow boxes).

Each software module (Kernel C-n, External Library 1, External Library 2 and External Library n) shall have is unique Checksum.

So the Full Module Checksum must be computed over all software module libraries.

Same for the Kernel C-m. So yellow external librairies/modules are included in two different checksums.

The value of Kernel C-n checksum and the value of Kernel C-m checksum shall be different.

Note: All Checksum computation changes are considered as a Major Change of the Application kernel and require new approval.

Note: Products submitted for renewal, where initial submissions were accepted without the present Checksum rules, are allowed for renewal submission without the present Checksum rules.

Note: Additional Configurations of a Multi Configuration Product, where baseline



configuration was accepted without the present Checksum rules, are allowed for additional configuration submission without the present Checksum rules.