PCI Watch

Tracking changes across the Payment Card Industry

EMV® Card Type Approval – CPA Levels 1 & 2 – Administrative Process

v2.8.r Type Approval Process
Contact Card

EMV® Card Type Approval CPA Levels 1 & 2 Administrative Process Version 2.8.r September 2025

v2.8.r Page i / vii

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 noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, 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.

v2.8.r

/ vii Revision Log – Version 2.8.r The following changes have been made to the document since the publication of Version 2.8. 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. Incorporated changes described in the following Specification Updates:

  • None Other editorial changes:
  • Editorial updates v2.8.r 1. 1. 1.2. 1.2. 1.2. 1. 1. 1.4. 1.4. 2. 2.1. 2.1. 2. 2.2. 2.2. 2.2. 2. 2. 2. 3. 3. 3. 3.3. 3.3. 3.3. 3.3. 3. 3. 3. 3.6. 3.6. 3. v2.8.r / vii 3. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4. 4.14. 4.14. 4. 4.15. 4.15. 4.15. 4.15. 5. 5. 5. 6. 6. 6. 7. 7.1. 7.1. 7. 7. v2.8.r Page v / vii 7. 7. 7. 7.6. 7. 7. 7. 7. 8. 8. v2.8.r v2.8.r v2.8.r / 60 1

Introduction

EMVCo, LLC (“EMVCo”) is the owner of the EMV Integrated Circuit Card Specifications for Payment Systems, EMV Common Payment Application Specification, hereinafter called EMV Specifications. All readers of this document are advised that Card 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 review the legal notice on page i of this document for important limitations on the scope of Type Approval. Card Type Approval is the verification by EMVCo that a specific card product has demonstrated sufficient conformance to the EMV specifications. The Card Type Approval process includes both functional and security evaluations. This document describes functional evaluation. Limited information regarding security evaluation is included for completeness. (See [Sec Gd]1 for details of security evaluation.) This version of the document focuses on Card Type Approval for card products implementing the Common Payment Application (CPA) specifications. A separate version addresses Card Type Approval for card products implementing the Common Core Definitions (CCD) specifications.

1.1 Audience This document is intended for all stakeholders interested in Card Type Approval, including but not limited to:

  • Chip Providers,
  • Specification Owners,
  • Product Providers,
  • EMVCo Recognised Laboratories,
  • And EMVCo Qualified Auditors. It is assumed that the reader is familiar with EMV specifications, in particular with the Common Core Definitions (CCD), with the Common Payment Application (CPA) specification, and with the EMV® Card Personalization Specification. 1 The normative references are listed in section 1.2. v2.8.r / 60 1.2 Normative

References

The version numbers identified in the references below are valid at the time of release of this document. Nevertheless, the latest version available from EMVCo should apply.

1.2.1 EMV Specifications EMVCo, LLC (EMVCo) manages and maintains the EMV Integrated Circuit Card (ICC) Specifications for Payment Systems, hereinafter called the EMV specifications. EMV specifications are publicly available on the EMVCo website: www.emvco.com. Reference [EMV Book 1] [EMV Book 2] [EMV Book 3] [EMV Book 4] [EMV Contact L1] [EMV CPS] [EMV CPA] Table 1-1: EMV Specifications Publication Name EMV® Integrated Circuit Card Specifications for Payment Systems: Book 1 – Application Independent ICC to Terminal Interface Requirements EMV® Integrated Circuit Card Specifications for Payment Systems: Book 2 – Security and Key Management EMV® Integrated Circuit Card Specifications for Payment Systems: Book 3 – Application Specification EMV® Integrated Circuit Card Specifications for Payment Systems: Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements EMV® Level 1 Specifications for Payment Systems, EMV Contact Interface Specification EMV® Card Personalization Specification EMV® Integrated Circuit Card Specifications for Payment Systems: Common Payment Application Specification All Specification Update Bulletins as published on the EMVCo website Version Latest available Latest available Latest available Latest available Latest available Latest available Latest available Latest available

v2.8.r 1.2.2 Card Type Approval Documents

/ 60 Reference [AP CCD] [Aud Qual Req] [Lab Reco Req] [Sec Gd] [Sec Impl Gd] [Cd Img CCD] [Cd Img CPA] [TC L1] [TC CCD] [TC CPA] Table 1-2: Card Type Approval Documents Publication Name Version Distribution EMVCo Card Type Approval Administrative Process for CCD EMVCo Qualification Requirements for Auditors (Card and Mobile Functional Evaluation) EMVCo Laboratory Recognition and Requirements EMV Security Guidelines – EMVCo Security Evaluation Process CPA Secure Implementation Guidelines Latest Available Latest Available Latest available Latest Available EMVCo Card Type Approval CCD Level 1 and Level 2 Images Requirements EMVCo Card Type Approval CPA Level 1 and Level 2 Images Requirements EMVCo Card Type Approval Card Level 1 Electrical and Protocol – Test Cases Latest Available Latest Available Latest Available EMVCo Card Type Approval Latest CCD Level 2 – Test Cases Available EMVCo Card Type Approval Latest CPA Level 2 Test Cases Available EMVCo Website EMVCo Website EMVCo Website EMVCo Website Upon Request from the SEWG (Restricted to Chip Providers and Product Providers that have signed the EMVCo Certification Contract Security Evaluation) EMVCo Website EMVCo Website Restricted to Test Tool Suppliers, EMVCo Recognised Laboratories, and EMVCo Qualified Auditors Restricted to Test Tool Suppliers, EMVCo Recognised Laboratories, and EMVCo Qualified Auditors Restricted to Test Tool Suppliers, EMVCo Recognised Laboratories, and EMVCo Qualified Auditors

v2.8.r

/ 60 1.2.3 Card Type Approval Forms Table 1-3: Card Type Approval Forms Publication Name Version Distribution Request for Registration for Chip Providers Request for Registration for Product Providers Business Review Form for Chip and Product Providers EMVCo CPA Implementation Conformance Statement Level 1 & 2 (ICS) Request for Approval Form Approved Card Product Change Request Request for Renewal of Card Product Approval Request for Additional CPA Functions Review Latest available Latest available Latest available Latest available Latest available Latest available Latest available Latest available EMVCo Website EMVCo Website EMVCo Website EMVCo Website EMVCo Website EMVCo Website EMVCo Website EMVCo Website 1.3

Definitions

The following terms are used in this specification: Table 1-4: Definitions Term Definition Additional CPA Functions Approved chip Audit report Card Compliance Certificate Number (CCN) Card product Card sample A specification, based on the CPA specifications, created by an entity other than EMVCo to describe additional CPA functions An Integrated Circuit that has received an IC Compliance Certificate, which indicates that it meets EMVCo security conformance requirements. A report written by an EMVCo Qualified Auditor assessing, for example, Card Type Approval test results or laboratory test processes. A number assigned by the Security Evaluation Secretariat when confirming that a Card Security evaluation is acceptable. A payment card as defined by a Payment System. For the purpose of this document, a card product is comprised of an Integrated Circuit, Operating System, environment, and one (or more) EMV Application(s). See section 2.1.1. A card representative of a specific card product provided to a laboratory for testing.

v2.8.r

/ 60 Card Security evaluation Card Type Approval Card Type Approval documentation Card Type Approval process Card Type Approval Secretariat CCD Components Chip Provider Chip Security evaluation Common Core Definitions Common Payment Application Conformance The process by which EMVCo assesses the security of a card product and how its components conform to EMVCo’s security guidelines. Verification by EMVCo that a specific card product has demonstrated sufficient conformance to the EMV specifications. Set of documents and procedures issued by EMVCo describing EMVCo Card Type Approval process (documents are listed in section 1.2.2). The steps necessary for a card product to obtain an EMVCo Letter of Approval. The EMVCo entity that manages the Card Type Approval process. The part of an EMV Application that is defined in the EMV CCD specifications. A vendor that submits Integrated Circuit(s) to EMVCo for security evaluation. The process by which EMVCo assesses the security of an Integrated Circuit that will be used in card products. A subset of the EMV specifications that:

  • describes the minimum set of functions and data mandatory for an EMV Application
  • describes a set of functions and data that may be implemented
  • excludes other functions and data described in other parts of the EMV specifications See: [EMV Book 1],2 Part V [EMV Book 2], Part IV [EMV Book 3], Part V An application that:
  • complies with the EMV Common Core Definitions
  • supports a core set of functionalities
  • can be personalized with the same data elements to meet the business requirements of multiple Payment Systems Described in [EMV CPA]. Meeting all EMVCo requirements defined for Card Type Approval including implemented optional requirements. 2 The normative references are listed in section 1.2. v2.8.r / 60 Delta Testing Differential Testing Dual Interface EMV Application EMV CPA EMVCo EMVCo Recognised Laboratory EMVCo Qualified Auditor Environment IC Compliance Certificate Implementation Conformance Statement (ICS) Integrated Circuit Card (ICC) Integrated Circuit(s) (IC) International Organization for Standardization (ISO) Laboratory Letter of Acceptance Testing that covers 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. Testing that covers the difference between the original product and the derivative product independently of the test plan being updated or not. Note: Testing will be determined on a case by case basis depending on the change A card that has both contact and contactless interfaces with one or more applications active on each of the interfaces. A payment application which conforms to the EMV specifications and is submitted to EMVCo for Card Type Approval. An EMV Application that conforms to [EMV CPA]. The organization that manages the EMV specifications and their related testing processes.. An independent, impartial entity that has received a Letter of Recognition from EMVCo, entitling it to perform testing for Card Type Approval. An independent, impartial entity that has received a Letter of Qualification from EMVCo, entitling it to verify conformance to EMVCo-defined Card Type Approval procedures. Any software components and/or applications present on the card product other than the EMV Application(s) being submitted for testing for Card Type Approval. A certificate issued by EMVCo, indicating that an Integrated Circuit meets EMVCo security conformance requirements. A form completed by the Product Provider identifying the card product, the EMV mandatory functions, the EMV optional functions supported, and (if any) the non-EMV proprietary functions. A card product into which one or more Integrated Circuits are inserted to perform processing and memory functions. Electronic component(s) designed to perform processing and/or memory functions. An international body that provides standards for financial transactions and telecommunication messages. ISO works in conjunction with the International Telecommunication Union (ITU) for standards that affect telecommunications. ISO supports specific technical committees and work groups to promulgate and maintain financial service industry standards. A facility that performs testing for Card Type Approval. Written statement that documents the decision of EMVCo that an audit report is acceptable. v2.8.r / 60 Letter of Recognition Letter of Approval Letter of Rejection Letter of Qualification Level 1 evaluation Level 2 evaluation Multi-application card Multi-protocol card Operating System (OS) Payment System Product Provider Recognition Registration Letter Registration Number Written statement that documents the decision of EMVCo that a laboratory is an EMVCo Recognised Laboratory and performs testing for Card Type Approval in conformance with the rules defined by EMVCo. Written statement that documents the decision of EMVCo that a specified card product has demonstrated sufficient conformance to the EMV specifications as of its test date. Written statement that documents the decision of EMVCo that a specified card product has NOT demonstrated sufficient conformance to the EMV specifications as of its test date. Written statement that documents the decision of EMVCo that an auditor is an EMVCo Qualified Auditor and performs audits for Card Type Approval in conformance with the rules defined by EMVCo. Execution and reporting on the results of a defined set of electrical, mechanical, and communication protocol tests to verify conformance to the requirements defined in [EMV Contact L1]. Execution and reporting on the results of a defined set of functional tests to verify conformance to the requirements defined in [EMV Book 1], [EMV Book 2], [EMV Book 3] and [CPA]. A card product that contains more than one application, one of which is an EMV Application. A card product that supports both protocol T=0 and protocol T=1. Set of software components allowing an EMV Application to be executed on a specific Integrated Circuit. For the purpose of this document, Payment System is defined as American Express or Discover or JCB or Mastercard or UnionPay or Visa. The entity that submits a card product to EMVCo for Card Type Approval. Formal recognition by EMVCo that a test laboratory is competent to perform one or more categories of testing defined by EMVCo Card Type Approval procedures. Written statement provided by the Card Type Approval Secretariat including the Registration Number of the Chip Provider or Product Provider. Unique identification number that EMVCo assigns to a Chip Provider, Product Provider, EMVCo Qualified Auditor, or EMVCo Recognised Laboratory. v2.8.r / 60 Regression Testing Request for Approval Request for Approval Form Security Evaluation Secretariat Specification Owner Test Test case Test report A predefined subset of functional test cases executed to determine whether undeclared changes have been made to the originally approved product. Regression Testing may be performed when Delta Testing is not required. The entire package submitted by the Product Provider (or by a laboratory on behalf of the Product Provider), including the Request for Approval Form and other information as discussed in section 4.9. A form that accompanies the test reports for a card product submitted to EMVCo for Card Type Approval. The EMVCo entity responsible for evaluating chip and card security for Card Type Approval. Entity other than EMVCo (e.g. a payment organization or card issuer) responsible for the Owner Specification contents. Any activity that aims at verifying the conformance of a selected product or process to a given requirement under a given set of conditions. A description of the actions required to achieve a specific test objective. Document provided by a laboratory containing the test results for a card product.

1.4 Notational Conventions 1.4.1 Abbreviations The abbreviations listed in Table 1-5 are used in this specification. Abbreviation CCD CPA IC ICC ICS ISO OS SEWG Table 1-5: Abbreviations

Description

Common Core Definitions Common Payment Application Integrated Circuit Integrated Circuit Card Implementation Conformance Statement International Organization for Standardization Operating System Security Evaluation Working Group

v2.8.r

/ 60 1.4.2 Terminology and 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.

v2.8.r 2 Scope of Card Type Approval

/ 60 2.1 Concept and Terminology 2.1.1 Card Product Definition As illustrated in Figure 2-1, the card product submitted for Card Type Approval is uniquely defined as:

  • the EMV Application(s)
  • present on a specific Integrated Circuit (contact interface) that has received an EMVCo IC Compliance Certificate
  • with a specific Operating System and transmission protocol(s)
  • and a specific Environment including any other application not covered by EMVCo Card Type Approval and/or software components Figure 2-1: Card Product Definition EMV Application(s) Environment Including applications not covered by EMVCo Card Type Approval and/or software components Operating System and transmission protocol(s) Specific Integrated Circuit 2.1.2 CPA Application The Common Payment Application Specification defines the data elements and functionality for an application that complies with the EMV Common Core Definitions. It focuses on the functions performed by the Integrated Circuit Card (ICC) and the interaction between the ICC and terminal at the point of transaction. The objectives of the Common Payment Application Specification are to:
  • Describe the functionality of a CCD-compliant implementation of EMV to ease vendor development efforts
  • Specify a core set of functionalities that issuers can rely on having available in every implementation of CPA
  • Specify an implementation that can be personalized with the same data elements to meet the business requirements of multiple Payment Systems
  • Because CPA is based on EMV and CCD, the specifications should be used together for reference and development purposes. v2.8.r / 60 2.2 Scope of Card Type Approval EMVCo issues a Letter of Approval for a card product when the Product Provider has successfully completed all the EMVCo evaluations listed in Table 2-1 Table 2-1: EMVCo Evaluations for Card Type Approval Prerequisite: Chip Security evaluation Card Functional Level 1 evaluation evaluation
  • EMV Level 1 electrical evaluation
  • EMV Level 1 protocol evaluation Note: Non-EMV Level 1 options must follow the same audit process as NonCCD Components. See [AP CCD]. Level 2 evaluation
  • CCD functional evaluation
  • CPA functional evaluation Note: additional CPA functionalities must follow the audit process described in section 4.4 Card Security evaluation The Level 1 and Level 2 evaluations are performed on the CPA options as listed in the Implementation Conformance Statement (ICS) submitted by the Product Provider. The Level 1 and Level 2 evaluations are limited to the complete EMV Application(s) submitted for Card Type Approval; any other feature of the card product not covered when testing the EMV Application(s) is out of scope of EMVCo’s Card Type Approval. EMVCo Card Type Approval does not address or supersede the payment schemes card issuance and personalization requirements. Please contact the payment schemes to obtain more information regarding their vendor approval/authorization programs and other card issuance and personalization requirements 2.2.1 Level 1 Evaluation

Scope

The Level 1 evaluation covers the electrical characteristics, the logical interface, and the transmission protocols of the card product containing one (or more) EMV Application(s). The Protocol portion of the Level 1 evaluation must be performed at an EMVCo Recognised Laboratory. The Electrical portion of the Level 1 evaluation must be performed at an EMVCo Recognised Laboratory.

2.2.2 Level 2 Evaluation Scope The Level 2 evaluation may consist of two parts:

  • The Level 2 evaluation is a functional evaluation of the EMV CPA Application according to the CPA specification. This evaluation is based on the CCD and CPA Level 2 Test Cases defined by EMVCo in [TC CCD and [TC CPA].
  • And optionally a functional evaluation of the Additional CPA functions according to the Owner Specification. v2.8.r / 60 The Additional CPA functions evaluation must cover all other functionality of the Owner Specification that involves an EMV transaction but is not covered by the CPA specifications. Before this evaluation occurs, the additional CPA functions specifications must have been audited and the audit report must have been accepted by EMVCo. A card product submitted for Card Type Approval may be a single or multi-application card, but the Level 2 evaluation addresses only the EMV Application(s) on the card and the mechanisms used for its/their selection. EMVCo Card Type Approval of a card product does not evaluate the card platform (card Operating System, such as Java Card, MULTOS, or any native OS), but evaluates one or more EMV Applications on the same card that are built to the CPA specifications.

2.2.3 Debug Sessions Debug sessions occur between the laboratory and the Product Provider, and are beyond the scope of EMVCo.

2.3 Scope of a Multi-Application Card For the purpose of this document, a multi-application card is defined as a card product with both EMV CPA and non-CPA non-CCD applications as defined by a Specification Owner. This card must satisfy the EMV CPA requirements outlined in this document and the Specification Owner specific protocol and application requirements. Note 1: For further information re: non-CPA applications built to EMV CCD specifications see ‘EMVCo Card Type Approval Administrative Process for CCD’ documentation. For testing and approval purpose, a multi-application card implementing the CPA specifications shall undergo and pass both EMVCo Level 1 and Level 2 testing requirements and the Specification Owner specific protocol and application testing requirements for the non-CPA non-CCD application(s). While EMVCo evaluates and type approves the CPA and CCD application(s) of a multi-application card, when other non-CPA non-CCD application(s) is(are) present, product approval for multi-application cards is administered by the Specification Owner. Note 2: Approval by the Specification Owner (e.g. Payment System) is outside of the scope of EMVCo’s Card Type Approval.

v2.8.r

/ 60 2.4 Scope of a Dual Interface Card For the purpose of this document, a dual interface card is defined as a card product with both EMV CPA contact and Payment System contactless applications. This card must satisfy the EMV CPA contact requirements outlined in this document. For testing and approval purpose, a dual interface card implementing the CPA specifications shall undergo and pass both EMVCo contact testing which includes both Level 1 and Level 2 requirements and contactless testing which includes both EMVCo Common Analog and Digital requirements in addition to Payment Scheme digital and application testing requirements. While EMVCo evaluates and type approves the contact interface and CPA application(s) of a dual interface card, since Payment System specific contactless application(s) is(are) present, product approval for dual interface cards is administered by the Payment Systems. Changes to dual interface cards are managed by the individual Payment Systems. Note: Approval by the Payment System is outside of the scope of EMVCo’s Card Type Approval.

2.5 Chip and Card Security Evaluation Overview The main objective of the EMVCo Security Evaluation Process is to ensure that Integrated Circuits (IC), i.e. chips, and Integrated Circuit Cards (ICC), i.e. chip card products, conform to EMVCo security guidelines. The EMVCo Security Evaluation Process evaluates the security features of a card product’s chip as well as the card product’s Operating System and EMV Application(s). Chip Security evaluation Card Security evaluation This evaluation considers the security of the chip that will be used in the card product, and is aimed at providing high assurance in the security functions that are designed to effectively deal with known attack methods. If the Chip Security evaluation is successful, EMVCo issues an IC Compliance Certificate to the Chip Provider. The Product Provider must receive the IC Compliance Certificate number from the Chip Provider before the Product Provider can submit a card product with that chip for functional evaluation or Card Security evaluation. This evaluation considers the security of a card product and how its components conform to EMVCo’s security guidelines. An important factor is how the Product Provider builds upon the security of the chip and OS to provide overall security for an EMV Application(s) on the card. Please note that the EMVCo Security Evaluation applies to multi-application chip and card products as well as dual interface chip and card products.

v2.8.r

/ 60 3 Card Type Approval Overview The following sections provide an overview of the Card Type Approval process:

3.1 Generic EMVCo Type Approval Flow The following picture describes the generic steps applicable to any EMVCo Type Approval. Figure 3-1: Generic EMVCo Type Approval Flow

v2.8.r

/ 60 3.2 Card Type Approval Flow The generic flow is customized to address the specific requirements of a Card Type Approval Figure 3-2: Card Type Approval Flow Chip or Product Provider Registration No Yes Chip evaluated? Chip Registration Form Submitted Implementation Conformance Statement Submitted Chip Security Evaluation Card Functional Evaluation Level 1 Evaluation Level 2 Evaluation Card Security Evaluation Request for Approval Pay invoice Chip Approval Request IC Compliance Certificate Invoice paid No Invoice paid? Yes Letter of Approval including Card Compliance Certificate Number As discussed in section 2.1.1, a card product must include an Integrated Circuit that has received an EMVCo IC Compliance Certificate. Therefore, Chip Security evaluation, as described in section 2.5, is a prerequisite to Card Type Approval. Level 1 evaluation and Level 2 evaluation may be done in any order. When performed in parallel, any unsuccessful evaluation requires a complete re-evaluation of both Level 1 and Level 2. Level 1 evaluation and Level 2 evaluation may be executed by the same laboratory or by different laboratories depending on the laboratory capabilities or Product Provider preference. EMVCo recommends that the Card Security evaluation, as described in section 2.5, be performed after the Level 1 and Level 2 evaluations have been successfully completed. When performed in parallel, any unsuccessful evaluation requires a complete re-evaluation of Level 1, Level 2, and Card Security. Note: The same version number of the EMV application(s), operating system, and environment must be submitted for Level 1, Level 2, and Card Security evaluations.

v2.8.r 3.3 Reporting Results to EMVCo

/ 60 3.3.1 Reporting Level 1 Evaluation Results The Product Provider shall ask the EMVCo Recognised Laboratory to send the level 1 report directly to EMVCo. Figure 3-3: Reporting Level 1 Evaluation Results evaluation results Prerequisite: Chip Security Evaluation report to EMVCo report to Level 1 Electrical must be executed by an EMVCo Recognised Laboratory Level 1 Protocol* must be executed by an EMVCo Recognised Laboratory report to Product Provider report to * Non-EMV Level 1 options must follow the same audit process as Non-CCD Components. See [AP CCD] 3.3.2 Reporting Level 2 Evaluation Results The Product Provider shall ask the EMVCo Recognised Laboratory to send the level 2 report directly to EMVCo 3.3.3 All Test Reports Each audit report and each test report must include the ICS reference number on the cover page.

3.3.4 Request for Approval Upon receipt of a Request for Approval, the Card Type Approval Secretariat will invoice the product provider. After confirmation from the Financial Secretariat that all the required fees have been paid, it will assemble all the reports into one Request for Approval package. It is the Product Provider’s responsibility to ensure that all required items are received by EMVCo. The Request for Approval will not be reviewed until payment of all required fees and all required items have been received.

v2.8.r

/ 60 3.4 General Rules for a Test Session The following rules must be followed by the laboratory performing the Level 1 and/or Level 2 evaluation:

  • The Product Provider must not be present during the testing of the card product.
  • Card products must be tested against the currently supported Test Cases version(s), and with an EMVCo Qualified Test Tool.
  • No modifications are allowed to the card product (as defined in section 2.1.1). If any modification is made to the card product during the test session, the session must end and the Product Provider must initiate a new submission including a new ICS.
  • If any modification is made to the ICS during the test session (without any modification to the card product), the modified ICS must be sent to EMVCo. The modified ICS is reviewed by EMVCo and if acceptable retains the validity period of the original EMVCo-accepted ICS. Note: Modification of the ICS is subject to a fee (See Section 3.6).

3.5 Submitting a Request for Approval Form A Request for Approval Form, completed in its entirety, must be submitted by the Product Provider after testing is complete, as discussed in section 4.9. Product Providers may submit a preliminary Request for Approval Form during the Testing Phase, at any point after EMVCo notifies the laboratory that the ICS is acceptable (as discussed in section 4.5). If the form is submitted early, EMVCo will invoice the Product Provider and the Product Provider can pay the administrative fees before test reports are available. Given that test reports are not reviewed until EMVCo has received payment of all fees, early payment avoids delays during the Approval Phase. Additionally, at this stage, to assist Product Providers with opening Purchase Orders, they may request a Statement of Work (SOW) from EMVCo that will list the services being provided and the fees associated.

3.6 Fee Structure EMVCo will charge fees to cover the administrative expenses incurred by EMVCo in managing the Card Type Approval process. This process includes, but is not limited to:

  • review of audit and test reports
  • updates to the Card Type Approval documentation, specifications, and Test Cases
  • maintenance of the EMVCo website, including lists of approved card products, EMVCo Recognised Laboratories, and EMVCo Qualified Auditors The following fee shall be paid to EMVCo by the Product Provider:
  • Audit report for Additional CPA Functions Owner Specification fee for the review of the audit report for Additional CPA Functions Owner Specification. It has to be paid by the first Product Provider to submit the specification audit report (Subsequent Product Providers using the same EMVCo accepted audit report will not have to pay this fee.) v2.8.r / 60
  • Request for Approval fee for a review of a Request for Approval for a CPA Card Product (including security evaluation)
  • Change Request fee for a review of an Approved CPA Card Product Change Request (including security evaluation)
  • Request for Renewal fee for a review of a Request for Renewal of CPA Card Product Approval (including first security evaluation)
  • Re issuance of a Letter of Approval fee for a re-issuance of a Letter of Approval at the explicit request of the vendor (e.g. company or addressee name/address change).
  • ICS Replacement fee. One free ICS replacement is allowed during the ICS life cycle. Any subsequent ICS replacement requested is charged to the Product Provider:
  • Same submission process applies as for initial ICS submission (Laboratory submits the changed ICS).
  • 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.
  • ICS replacement is not allowed after Test Report submission to EMVCo The following fee shall be paid to EMVCo by the laboratory
  • ICS decline fee if an incomplete and/or inconsistent ICS is submitted to EMVCo for review (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)
  • Test report decline fee if an incomplete and/or inconsistent test report is submitted to EMVCo for review Note 1: The amount of each fee is published in the Card Type Approval bulletin 26 available on EMVCo Website. Please check the EMVCo website for the latest fee amounts Note 2: Payers are responsible for any bank charges associated with remittance. Each Paying entity must work with its bank to ensure that EMVCo receives the full amount of the fee. The Request for Approval will not be reviewed until complete payment has been received. Note 3: The audit fees charged by an EMVCo Qualified Auditor to review Non-EMV Level 1 options or additional CPA functionalities are not included and are the responsibility of the Chip or Product Provider. Note 4: The testing fees charged by the EMVCo Recognised Laboratory to execute test cases are not included and are the responsibility of the Product Provider. Note 5: Check the SEWG bulletin for details on the fees charged for security review. v2.8.r / 60 3.6.1 Fee Structure for Multi-application Cards When the Product Provider identifies in the initial Implementation Conformance Statement (ICS) several environments (as defined in section 2.1.1) with different multi-application configurations, an impact assessment on the CPA application must be submitted with the ICS and the following fees must be paid by the Product Provider:
  • Request for Approval fee for the review of a Request for Approval
  • Reduced Request for Approval fee for the review of each additional environment that EMVCo determines requires additional testing Note: The reduced request for Approval fee is available only if the additional multi-application configuration(s) are listed on the original ICS submitted for EMVCo acceptance. If one or more additional multi-application configurations are requested after EMVCo approval of the original Request for Approval, the additional configuration(s) must be submitted through the Change to Approved Product process and the standard Request for Approval fee for review of an Approved Card Product Change Request applies.

3.6.2 Fee Structure for Multi-protocol Cards For a card product that implements both T=0 and T=1 protocols, two ICS shall be submitted, one for each protocol. If two ICSs are identical except that one describes protocol T=0 and the other describes protocol T=1, and if the ICSs are submitted together as “initial submission” (question A.2.1 of the ICS), then the following fees must be paid by the Product Provider:

  • Request for Approval fee for the review of a Request for Approval
  • Reduced Request for Approval fee for the review of the second Request for Approval Note 1: The reduced Request for Approval fee is available only if the ICSs for the multi-protocol chip card are submitted together. As a result, it does not apply if the second product is submitted as a derivative product (ICS of the derivative product has to include the LOA of the parent product). Note 2: full Level 1 and full Level 2 testing is required for both the T=0 and T=1 products if the two ICS are submitted as “initial submission”.

3.7 EMVCo Service Levels The service level for the issuance of a Letter of Approval for a report showing 100% compliance shall be 5 business days from the receipt of all required documentation and payment of any applicable fees. The service level for ICS review shall be 3 business days. The service level for a change request or a renewal request review shall be 8 business days. EMVCo strives to provide the optimum service levels for all activities, but it cannot commit to service levels for matters that require investigational work, such as reviewing reports not showing 100% compliance.

v2.8.r

/ 60 3.8 Multiple Laboratories Level 1 and Level 2 testing can be split between different laboratories. When this is the case the following rules shall apply:

  • A single laboratory is responsible for the Level 1 and Level 2 functional testing (primary laboratory).
  • The primary laboratory may subcontract some testing to other laboratories (subcontracted laboratories)
  • The primary laboratory and the subcontracted laboratory shall be recognised for the subcontracted testing
  • Agreement shall be in place between the laboratories to support the subcontracting work,
  • The Product Provider shall be informed and shall agree that some or full testing will be sub-contracted to another Recognised Laboratory,
  • The primary laboratory submits the ICS to EMVCo.
  • The primary laboratory shall create, sign and submit to EMVCo all test reports.
  • All samples shall be sent to the primary laboratory that will dispatch some of them to the subcontracted laboratory,
  • All samples shall be returned to the primary laboratory and kept by the primary laboratory after the testing,
  • All session results and logs shall be made available to the Primary Laboratory responsible for their archive,
  • The subcontracted laboratories shall follow EMV rules.
  • The primary laboratory will be responsible for subcontracted laboratories defects and may require additional audit.
  • In case of ICS issue, fees will only be applied to the primary laboratory
  • The primary laboratory shall document the sub contracted work into the test report
  • When testing is conducted at multiple laboratories, all test reports received must contain the same version number of the EMV application(s), operating system, and environment.
  • All rules regarding the samples shall be maintained. All sets of card samples at all laboratories are for the same version of the ICS. The reports shall clearly indicate which samples were tested at each laboratory. v2.8.r / 60 4 Card Type Approval Procedures The following sections describe the Card Type Approval procedures. Note: This document frequently requests one entity to send a form, a test report, or an audit report to EMVCo. Unless otherwise specified, all such materials must be sent to the Card Type Approval Secretariat (card_approval@emvco.com).

4.1 Chip Provider Registration As illustrated in Figure 4-1, the Chip Provider Registration process is as follows:

  • The Chip Provider:
  • Obtains registration information from the EMVCo website
  • Submits completed Request for Registration and Business Review forms (including a Dun & Bradstreet report or equivalent in English) to the Card Type Approval Secretariat (card_approval@emvco.com).
  • EMVCo reviews the submitted materials and, if acceptable, sends the EMVCo/Chip Provider contract to the Chip Provider
  • The Chip Provider executes the contract with EMVCo Note 1: The contract between EMVCo and the Chip Provider must be completed before the Chip Security evaluation described in section 4.3 begins.
  • The Security Evaluation Secretariat provides the Chip Provider with the Secure Implementation Guidelines [Sec Impl Gd].
  • The Card Type Approval Secretariat provides the Chip Provider with a Registration Letter which will include the Chip Provider’s Registration Number. Note 2: The registration process is completed only once per Chip Provider. v2.8.r Figure 4-1: Chip Provider Registration / 60 Start Chip Provider submits completed Request for Registration and Business Review forms to EMVCo Forms complete? N Y Business review accepted by EMVCo? N Y EMVCo enters Chip Provider’s information into EMVCo database and sends Chip Provider contract for signature Chip Provider submits completed contract to EMVCo EMVCo informs Chip Provider of incomplete information EMVCo informs Chip Provider of rejection of business review Contract complete? N Y EMVCo sends Chip Provider a copy of signed contract and [Sec Impl Gd] EMVCo provides Registration Letter including Registration Number to Chip Provider End EMVCo informs Chip Provider of incomplete contract information 4.2 Card Product Provider Registration3 As illustrated in Figure 4-2, the Product Provider Registration process is as follows:
  • The Product Provider:
  • Obtains registration information from the EMVCo website
  • Submits completed Request for Registration and Business Review forms (including a Dun & Bradstreet report or equivalent in English) to the Card Type Approval Secretariat (card_approval@emvco.com) 3 Product Provider registration can be performed concurrently with, or after, selecting a laboratory. v2.8.r / 60
  • EMVCo reviews the submitted materials and, if acceptable, sends the following contracts to the Product Provider:
  • EMVCo/Product Provider contract for Card Type Approval from the Card Type Approval Secretariat
  • EMVCo/Product Provider contract for Security Evaluation from the Security Evaluation Secretariat (securityevaluation@emvco.com)
  • The Product Provider executes the contracts with EMVCo Note 2: The contract for Card Type Approval must be executed before the testing phase described in section 4.5 begins. The contract for Security Evaluation must be executed before the Card Security evaluation described in section 4.6 begins.
  • The Security Evaluation Secretariat (securityevaluation@emvco.com) provides the Product Provider with the Secure Implementation Guidelines [Sec Impl Gd]
  • The Card Type Approval Secretariat provides the Product Provider with a Registration Letter which will include the Product Provider’s Registration Number. Note 3: The registration process is completed only once per Product Provider. If the Product Provider has already registered for CCD Card Type Approval, registration does not have to be done again for CPA and vice versa. Note 4: EMVCo Letters of Approval are addressed to the primary contact identified on the Request for Registration. v2.8.r Figure 4-2: Card Product Provider Registration Start Product Provider submits completed registration and business review forms to EMVCo / 60 Forms complete? N EMVCo informs Product Provider of incomplete information Y Business Review accepted? N EMVCo informs Product Provider of rejection of business review Y EMVCo enters Product Provider’s information into EMVCo database and sends Product Provider contracts for signature Product Provider submits completed contracts to EMVCo Contracts complete? Y EMVCo sends Product Provider a copy of signed contracts and [Sec Impl Gd] EMVCo provides Registration Letter including Registration Number to Product Provider End N EMVCo informs Product Provider of incomplete contract information v2.8.r / 60 4.3 Chip Security Evaluation The Chip Provider pays required administrative fees to EMVCo for a review of the Chip Security evaluation. The Chip Provider submits the Chip Security Evaluation Report directly to the Security Evaluation Secretariat (securityevaluation@emvco.com) (not to the Card Type Approval Secretariat). Detailed information about the Chip Security evaluation and chip approval is provided in [Sec Gd].

4.4 Audit Phase In case the CPA product supports additional CPA functionalities as section 19 of [EMV CPA], an audit phase of the product is required. As illustrated in Figure 4-3 and described below, the Audit Phase involves the Owner Specification of the Additional CPA Functions.

  • The Specification Owner of the Additional CPA Functions (or the Product Provider on behalf of the Specification Owner):
  • Selects one (or more) EMVCo Qualified Auditor(s) from the list published on the EMVCo website and executes required bilateral agreements and contracts Note 1: The Specification Owner must ensure that the auditor chosen is independent of the Specification Owner.
  • Provides a detailed EMV Additional CPA Functions specification - the Owner Specification - to the EMVCo Qualified Auditor(s)
  • The EMVCo Qualified Auditor(s) ensures that:
  • All mandatory CPA requirements are correctly supported
  • All Additional CPA Functions requirements in the Owner Specification are in accordance with the EMV specifications and bulletins
  • All requirements for Additional CPA Functions in the Owner Specification do not conflict with anything in the EMV specifications and bulletins
  • The EMVCo Qualified Auditor(s) then creates an audit report (in English), and submits the audit report(s) to the Specification Owner.
  • The Specification Owner authorizes the Product Provider, or optionally the EMVCo Qualified Auditor(s), to submit the audit report(s) to EMVCo for evaluation.
  • The Product Provider pays required administrative fees to EMVCo for a review of the Owner Specification audit report. Note 2: The fee is required only if the Product Provider is the first one to submit the audit report to EMVCo for review. (See note following next step.)
  • EMVCo reviews the audit report(s). If it is acceptable to EMVCo, the Card Type Approval Secretariat notifies the Product Provider of acceptance of the specific version of the Owner Specification. v2.8.r / 60 Note 3: After EMVCo notifies the initial Product Provider that the audit report is acceptable, the Specification Owner may use the notification as desired. An accepted audit report may be reused by multiple Product Providers in their respective Requests for Approval as long as the report is current; i.e. the Owner Specification is based on the current EMV specification and bulletins and the Owner Specification of the Additional CPA Functions are unchanged. No audit of the Additional CPA Functions Components test cases is necessary. Figure 4-3: Owner Specification Additional CPA Functions Audit Start Specification Owner selects EMVCo Qualified Auditor(s) EMVCo Qualified Auditor(s) audits Owner Specification OR non-CCD test cases EMVCo Qualified Auditor(s) provides audit reports to Specification Owner Specification Owner authorizes audit reports to be provided to EMVCo Product Provider pays fees for audit report review to EMVCo Product Provider OR EMVCo Qualified Auditor submits audit report to EMVCo Audit report acceptable? Y EMVCo notifies Product Provider of EMVCo acceptance N EMVCo informs Product Provider of non-acceptance End v2.8.r / 60 4.5 Testing Phase The Product Provider:
  • Selects one test laboratory from the list of EMVCo Recognised Laboratories published on the EMVCo website and executes bilateral required agreements and contracts Note 1: The Product Provider must ensure that the laboratory chosen is independent of the Product Provider.
  • Sends a fully completed and signed Implementation Conformance Statement (ICS) to the selected laboratory for each card product that it submits, along with product samples. Note 2: The ICS format and content are defined by EMVCo. The ICS must be the current valid ICS form as published by EMVCo. Note 3: If a card product supports both T=0 and T=1 protocol, a separate ICS must be submitted for each protocol. The protocols w

Shown in part. Read the original for the full text.