EMV. Terminal Type Approval Contactless Product. Administrative Process. Version 2.6 February 2017

Transcription

1 EMV Terminal Type Apprval Cntactless Prduct Administrative Prcess Versin 2.6 February 2017

2 Legal Ntice Page i / v Legal Ntice This dcument summarizes EMVC s present plans fr evaluatin services and related plicies and is subject t change by EMVC at any time. This dcument des nt create any binding bligatins upn EMVC r any third party regarding the subject matter f this dcument, which bligatins will exist, if at all, nly t the extent set frth in separate written agreements executed by EMVC r such third parties. In the absence f such a written agreement, n prduct prvider, test labratry r any ther third party shuld rely n this dcument, and EMVC shall nt be liable fr any such reliance. N prduct prvider, test labratry r ther third party may refer t a prduct, service r facility as EMVC apprved, in frm r in substance, nr therwise state r imply that EMVC (r any agent f EMVC) has in whle r part apprved a prduct prvider, test labratry r ther third party r its prducts, services, r facilities, except t the extent and subject t the terms, cnditins and restrictins expressly set frth in a written agreement with EMVC, r in an apprval letter, cmpliance certificate r similar dcument issued by EMVC. All ther references t EMVC apprval are strictly prhibited by EMVC. Under n circumstances shuld EMVC apprvals, when granted, be cnstrued t imply any endrsement r warranty regarding the security, functinality, quality, r perfrmance f any particular prduct r service, and n party shall state r imply anything t the cntrary. EMVC specifically disclaims any and all representatins and warranties with respect t prducts that have received evaluatins r apprvals, and t the evaluatin prcess generally, including, withut limitatin, any implied warranties f merchantability, fitness fr purpse r nn-infringement. All warranties, rights and remedies relating t prducts and services that have undergne evaluatin by EMVC are prvided slely by the parties selling r therwise prviding such prducts r services, and nt by EMVC, and EMVC will have n liability whatsever in cnnectin with such prducts and services. This dcument is prvided "AS IS" withut warranties f any kind, and EMVC neither assumes nr accepts any liability fr any errrs r missins cntained in this dcument. 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. EMVC makes n representatins r warranties with respect t intellectual prperty rights f any third parties in r in relatin t this dcument. EMVC undertakes n respnsibility t determine whether any implementatin f this dcument may vilate, infringe, r therwise exercise the patent, cpyright, trademark, trade secret, knw-hw, r ther intellectual prperty rights f third parties, and thus any persn wh implements any part f this dcument shuld cnsult an intellectual prperty attrney befre any such implementatin. Withut limiting the freging, this dcument may prvide fr the use f public key encryptin and ther technlgy, which may be the subject matter f patents in several cuntries. Any party seeking t implement this dcument is slely respnsible fr determining whether its activities require a license t any such technlgy, including fr patents n public key encryptin technlgy. EMVC shall nt be liable under any thery fr any party's infringement f any intellectual prperty rights in cnnectin with this dcument.

3 Revisin Lg Versin 2.6 Page ii / v Revisin Lg Versin 2.6 The fllwing changes have been made t the dcument since the publicatin f Versin 2.5. Sme f the numbering and crss references in this versin have been updated t reflect changes intrduced by the published bulletins. The numbering f existing requirements did nt change, unless explicitly stated therwise. Sectin Reasn fr change , Transactin Type Testing depending n the Kernel(s) present LA issuance when ne Kernel fails testing 2.4 ICS replacement rules Sample retentin plicy Appendix G & I Clarificatin f the testing when a Cntact Kernel is present in the Prduct

4 Cntents Page iii / v Cntents 1 INTRODUCTION AUDIENCE NORMATIVE REFERENCES DEFINITIONS NOTATIONAL CONVENTIONS Abbreviatins TERMINOLOGY & CONVENTIONS TYPE APPROVAL OVERVIEW SCOPE OF CONTACTLESS TYPE APPROVAL EMVC Cntactless Terminal Type Apprval Prcess Gal Cntactless Terminal Architecture: the Prduct Multi Kernel Envirnment Mdular Apprach Principles EMVCO CONTACTLESS TYPE APPROVALS DESCRIPTION Standard Prcess fr Cntactless Type Apprval Optimized Prcess fr Cntactless Type Apprval CONTACTLESS TYPE APPROVAL LIFE CYCLE CONCEPT Cntactless Prduct Life Cycle and Type Apprval Milestnes Prduct Design Phase Prduct Debugging Phase Prduct Apprval Phase Prduct Apprval Renewal Phase ICS SUBMISSION RULES ICS Submissin ICS replacement EMVCO TYPE APPROVAL FEE STRUCTURE Fees structure fr Standard Prcess Fees structure fr Optimized Prcess ROLES & RESPONSIBILITIES EMVCO EMVCO TYPE APPROVAL SECRETARIAT (CATA) AUDITORS EMVCO ACCREDITED LABORATORIES PRODUCT PROVIDER Mdular Cmpliance Request Type Apprval Request TYPE APPROVAL PROCEDURES... 32

5 Cntents Page iv / v 4.1 REGISTRATION CONTRACT WITH EMVCO REQUEST FOR COMPLIANCE Prduct Prvider and Auditrs Prduct Prvider Preparatin fr Cmpliance Request Prduct Prvider Request fr Cmpliance EMVC Apprval REQUEST FOR APPROVAL Prduct Prvider and Labratry Operatins Prduct Prvider Preparatin fr Apprval Request Prduct Prvider Request fr Apprval EMVC Apprval Optimized Prcess and Subsequent Submissin: Labratry Testing Prcedure ICS Submissin rules TYPE APPROVAL RENEWAL PROCESS Basic Plicy Labratries fr renewal testing Samples Submissin ICS Submissin TEST VERSION AND SPECIFICATION CHANGE TEST CHANGES WITHOUT SPECIFICATION UPDATE AND APPLICATION NOTE TEST CHANGES DUE TO SPECIFICATION UPDATE AND APPLICATION NOTE TESTING APPLICABILITY PRODUCT CHANGES CHANGE IN CONTACT APPENDIX A: TEMPLATES AND FORMS APPENDIX B: CHECKSUM IMPLEMENTATION RULES APPENDIX C: TYPE APPROVAL OF DERIVATIVE PRODUCT DEFINITION OF A DERIVATIVE CONTACTLESS PRODUCT TYPE APPROVAL PROCEDURES Derivative Cntactless Prduct Type Apprval apprach Derivative Cntactless Prduct Prcedures SUBSEQUENT SUBMISSION AND DERIVATIVE CONTACTLESS PRODUCT APPENDIX D: MODULAR ARCHITECTURE FOR TERMINAL WITH SEPARATE CONTACT/CONTACTLESS ARCHITECTURE APPENDIX E: CONTACTLESS TRADE MARK LICENSE APPENDIX F: CONTACTLESS KERNEL C-REGX PROCEDURE DEFINITION OF A CONTACTLESS KERNEL C-REGX TYPE APPROVAL PROCEDURES... 70

6 Cntents Page v / v Cntactless Prduct submitted fr the initial Apprval cntains a Cntactless Kernel C-REGx Cntactless Prduct submitted fr the subsequent Apprval with a Cntactless kernel C-x LA issuance APPENDIX G: MODULAR PRODUCT CONTAINING A CONTACT KERNEL CASE OF A MODULAR CONTACT KERNEL Definitin f a Mdular Cntact Kernel Type Apprval Prcedures LA issuance CASE OF A NON MODULAR CONTACT KERNEL PRESENT IN A MODULAR PRODUCT Definitin Type Apprval Prcedures APPENDIX H: AUTORUN PARAMETER TESTING APPENDIX I: CONTACTLESS PRODUCT PORTING INTO OTHER TERMINAL TYPE TYPE APPROVAL PROCEDURES Prduct Prvider and Labratry Operatins Testing prcedure fr apprval: Cntactless Prduct Prting Request fr Apprval... 77

7 Intrductin Page 1 / 78 1 Intrductin EMVC, LLC ( EMVC ) is the manager f the EMV Cntactless Specificatins fr Payment Systems- Bk A & B, Kernels C-1 t C-7 and Bk D Specificatins hereinafter called the EMV Cntactless Specificatins. EMVC s bjective described in this dcument is t prvide a Type Apprval prcess fr Cntactless Prduct that addresses the fllwing EMV Cntactless Specificatins: EMV Cntactless Specificatins fr Payment Systems Bk A & Bk B EMV Cntactless Specificatins fr Payment Systems Bks C-n Nte: EMV Cntactless Specificatins fr Payment Systems Bk D. The type Apprval prcess is addressed in a separate prcess dcument dedicated fr L1. Cmmn industry practice requires Prduct Prviders t accmmdate lcal Acquirer requirements in their Prduct. These Acquirer requirements are ut f the EMVC type apprval scpe. The Prduct Sftware Architecture plays a significant rle in determining whether cmplying with nn-emv acquirer requirements are likely t impact the apprved EMV Cntactless prduct. EMVC limits type apprval t the EMV Cntactless prduct, leaving the respnsibility t the apprpriate lcal acquiring entity (als referred t as the wner f the envirnment f use) t validate cntinued cmpliance with the EMV Cntactless Specificatins functinality in the integrated acquiring envirnment. All readers f this dcument are advised that type apprval, when granted by EMVC, shall nt be cnstrued as a warranty r representatin f any srt, nr may it be relied upn by any party as an assurance f quality r functinality f any prduct r service. Please nte the legal ntice stated abve at page 2 f this dcument fr imprtant limitatins n the scpe f type apprval. 1.1 Audience The target audience f this dcument includes: Prduct Prviders Labratries accredited t perfrm the type apprval tests Auditrs acting n behalf f EMVC 1.2 Nrmative References Table 1: Reference Dcuments Reference Publicatin name Bkmark [N1] EMV Integrated Circuit Card Specificatin fr Payment Systems Bk 1 Applicatin Independent ICC t Terminal Interface Requirements [N2] EMV Integrated Circuit Card Applicatin Specificatin fr Payment Systems Bk 2 Security and Key Management Versin 4.3 Nvember 2011 Versin 4.3 Nvember 2011

8 Intrductin Page 2 / 78 [N3] [N4] EMV Integrated Circuit Card Terminal Specificatin fr Payment Systems Bk 3 Applicatin Specificatin EMV Integrated Circuit Card Terminal Specificatin fr Payment Systems Bk 4 Cardhlder, Attendant, and Acquirer Interface Requirements [Bk A] EMV Cntactless Specificatins fr Payment Systems Bk A Architecture and General Requirements [Bk B] EMV Cntactless Specificatins fr Payment Systems Bk B Entry Pint Specificatin [Bk C-n] EMV Cntactless Specificatins fr Payment Systems Bk C-n kernel Specificatin [Bk D] EMV Cntactless Specificatins fr Payment Systems Bk D Cntactless Cmmunicatin Prtcl [ICS] EMVC Type Apprval Cntactless Prduct - Implementatin Cnfrmance Statement [TA A&B] EMVC Type Apprval Cntactless Prduct - Bk A & B Test Plan [TA P] EMVC Type Apprval Cntactless Prduct - Perfrmance Test Plan [TA M] EMVC Type Apprval Cntactless Prduct- Mdular Test Plan [TA Archi] EMVC Type Apprval Cntactless Prduct - Mdular Architecture Requirements [TA ADMIN L1] EMVC Type Apprval Cntactless Prduct Level 1 Administrative Prcess Versin 4.3 Nvember 2011 Versin 4.3 Nvember 2011 Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available Latest versin available [TA C-n] Kernel Test Plan Latest versin available [TB1] EMV Terminal Type Apprval Bulletin 185 Latest versin available 1.3 Definitins The fllwing terms are used in this specificatin: Card - A payment card as defined by a payment system. CATA Card And Terminal Apprval. Check Sum - A Prduct Prvider-generated value (minimum 4 bytes) fr each mdule. This checksum must be a unique value fr each mdule. The methd r algrithm used fr

9 Intrductin Page 3 / 78 generating the checksum is left t the discretin f the Prduct Prvider. Fr example, a Prduct Prvider may chse t implement SHA-1 r CRC. These values shall be easily retrievable fr each Kernel Mdule, Sftware Mdule, External Libraries r Entry Pint Mdule when laded in the Prduct and this fr cmparative purpses. Refer t annex B fr mre details n Checksum defined rules. Cmpliance - Meeting all the requirements including any implemented ptinal requirement(s). Cntactless Kernel C-REGX The prprietary kernel sftware lcated in the Cntactless Prduct where x is a registered Kernel ID using the EMVC kernel ID registratin prcess. C-REGX des nt refer t EMVC Kernel C-n. Entry Pint Mdule A POS System sftware managing applicatin (AID) and kernel selectin accrding t [Bk B]. Functin A prcess accmplished by ne r mre cmmands and resultant actins that are used t perfrm all r part f a transactin. Implementatin Cnfrmance Statement (ICS) - A frm cmpleted by the prduct prvider. The written statement lists all ptinal functins as specified in the EMV Cntactless Specificatins. Integrated circuit(s) - Electrnic cmpnent(s) designed t perfrm prcessing and/r memry functins. Internatinal Organizatin fr Standardizatin (ISO) - An internatinal bdy that prvides standards fr financial transactins and telecmmunicatin messages. ISO wrks in cnjunctin with the Internatinal Telecmmunicatin Unin (ITU) fr standards that affect telecmmunicatins. ISO supprts specific technical cmmittees and wrk grups t prmulgate and maintain financial service industry standards. Interface - Technical requirements fr exchanging data and functins between tw sftware mdules. Kernel C-n - Is a sftware Mdule cmpliant t ne f the [Bk C-n] specificatins. Letter f Apprval - Written statement that dcuments the decisin f EMVC that a specified Prduct has demnstrated sufficient cmpliance t the EMV Cntactless Specificatins n the date f testing. Lwer Tester Card simulatr f the test tl that cmmunicates with the prduct under test. The LT shall be in accrdance with sectin 7 f the present dcument.

10 Intrductin Page 4 / 78 Main Labratry The Labratry perfrming Bk A & B testing, Independency testing and Mdular testing fr a Prduct apprval. Majr mdificatin - Technical change t the EMV applicatin r additin t the applicatin that implies the prduct prvider cannt guarantee cntinued cmpliance f the mdified applicatin with the requirements f EMV Cntactless Specificatins, as defined by EMVC. Minr mdificatin - technical change t the EMV applicatin that des nt affect the functinality f the applicatin with respect t the requirements f EMV Cntactless Specificatins, as defined by EMVC. Mdular Architecture A sftware architecture that fllws the requirements defined in this dcument. A Prduct develped based n an Architecture that has received a Mdular Label can be submitted fr type apprval under the Optimized Prcess. Mdular Label - Written statement that dcuments the decisin f EMVC that the Prduct Prviders specified sftware architecture has demnstrated sufficient cmpliance t the EMV mdular requirements n the date f the audit. Optimized Prcess Type Apprval prcess fr Prduct(s) develped based n the Prduct Prviders Architecture that has received the Mdular Label and cntinues t adhere t the Mdular Architecture as cnfirmed by specific tests defined by EMVC. PCD - Prximity Cupling Device. A device f the Prduct that uses inductive cupling t prvide pwer t the PICC and als cntrls the data exchange with the PICC. POS System - Accrding t definitin Bk A in sectin 4.3. It is the device that cmmunicates with cntactless cards, prcesses cntactless transactins, and may supprt ther payment functinalities such as magnetic stripe r cntact chip transactins. Prcedure - Specified way t perfrm a set f tasks. Prduct - Accrding t the definitin in sectin 4.1. which defines the prduct t be type apprved during the Type Apprval prcess. Prficiency - Ability f a testing labratry t perfrm the specified tests in an exact and reprducible manner and t prvide an accurate test reprt. Prtcl - Methd f cmmunicatin between the ICC and the PCD, represented in this specificatin by Type A and Type B

11 Intrductin Page 5 / 78 Reference specificatin (EMV Cntactless Specificatins) - A set f dcuments defining the requirements the Prduct shall cmply with. The reference specificatin cnsists f the current EMV Cntactless Specificatins (Bk A, B, C-n, D) fr Payment Systems and any additinal dcumentatin required when perfrming type apprval. Registratin number - A unique identificatin number assigned by EMVC t a prduct prvider. Request fr apprval - A frm that ges with a prduct submitted t EMVC fr type apprval and marks the launch f its invice Sample - A prduct taken ut f the prductin line fr testing. Standard Prcess Type Apprval prcess fr Prduct which are nt cmpliant with the mdular architecture accrding t [TA Archi], Sftware Mdule - A self-cntained prgram that carries ut a clearly defined task and is intended t perate within a larger prgram suite. Mainly a mdule represents a Kernel C-n r Entry Pint. Terminal - Accrding t bk A definitin in sectin 5.1. Terminal culd be a standalne device r any netwrked slutin such as a POS, a ATM, a PIN PAD r any ther physical payment device. Test - Any activity that aims at verifying the cmpliance f a selected prduct r prcess t a given requirement under a given set f cnditins. Test case - A descriptin f the actins required t achieve a specific test bjective. Labratry - A facility accredited by EMVC t perfrm Type Apprval testing. Test Kernel Sftware simulating a Cntactless Kernel that must be present in the prduct under test fr testing reasn. The Test Kernel present shall be in accrdance with sectin 6.1 f the present dcument. Type apprval The acknwledgment by EMVC that the specified Prduct has demnstrated sufficient cmpliance t the EMV Cntactless Specificatins fr its stated purpse. Type apprval dcumentatin - Full set f dcuments and prcedures issued by EMVC t enable the type apprval prcess.

12 Intrductin Page 6 / 78 Type apprval prcess - The prcesses that test a prduct fr cmpliance with specificatin. 1.4 Ntatinal Cnventins Abbreviatins FIT ICC ICR ICS IEC IFM ISO Lab LA M-ICR ML PCD PICC RFA PRP S-ICR TTA Fully Integrated Terminal Integrated Circuit Card Integrated Card Reader Implementatin Cnfrmance Statement Internatinal Electrtechnical Cmmissin Interface Mdule Internatinal Organizatin fr Standardizatin Labratry Letter f Apprval Multi Cmpnent ICR Mdular Label Prximity Cupling Devices Prximity Integrated Circuit Card Request fr Apprval Prduct Prvider Single Cmpnent ICR Terminal Type Apprval 1.5 Terminlgy & cnventins The fllwing wrds are ften used in this specificatin and have a specific meaning: Shall

13 Intrductin Page 7 / 78 May Shuld Defines a prduct r system capability which is mandatry. Defines a prduct r system capability, which is ptinal r a statement which is infrmative nly and is ut f scpe fr this specificatin. Defines a prduct r system capability, which is recmmended. The fllwing cnventins apply: Value f Parameters Thrughut the specificatin, symbls are used t identify the values f parameters. The permitted values f the parameters are listed in Annex A and are written in Arial bld t distinguish them in the text. When used t define timings, frequencies, etc., it is the actual value that is intended. Fr example fc is the actual carrier frequency frm the PCD.

14 Type Apprval Overview Page 8 / 78 2 Type Apprval Overview 2.1 Scpe f Cntactless Type Apprval EMVC Cntactless Terminal Type Apprval Prcess Gal EMVC terminal type apprval cntactless ascertains the level f cnfidence that Prduct Prviders have crrectly implemented the EMV Cntactless Specificatins. Prduct Prviders submit their Prduct with the sftware and apprpriate dcumentatin, including the Implementatin Cnfrmance Statement (ICS), t an EMVC accredited Labratry fr testing. The Labratry executes a set f EMVC-defined test cases and prepares a test reprt dcument fr the Prduct Prvider that may then be submitted t EMVC fr evaluatin. EMVC s evaluatin f the test reprt cncludes with the issuance f a Letter f apprval r decline ntificatin. Obtaining an EMV Prduct apprval frm EMVC has the fllwing advantages: Acquirers have access t terminal implementatins in respect f which cmpliance t the EMV Cntactless Specificatins has already been tested - yielding a likely reductin in testing csts as well as imprved time t market fr final implementatins. Prduct Prviders can sell the apprved EMVC cmpliant prduct n a wrldwide basis and differentiate themselves frm the cmpetitin Cntactless Terminal Architecture: the Prduct This sectin defines the Cntactless Prduct (called the Prduct ) that is tested by the Cntactless Type Apprval prcess. The Prduct is based n the POS System defined in Bk A. A POS System is the device that cmmunicates with cntactless cards that prcesses cntactless transactins, and may supprt ther payment functinalities such as magnetic stripe r cntact chip transactins. The basic functins f the POS System include: Cmmunicatin with cntactless cards. Applicatin selectin and kernel activatin. Displaying messages t the cardhlder. Displaying messages t the merchant. Accepting merchant data entry f the transactin amunt. Cardhlder verificatin (e.g. signature). Prvisin f nline cnnectins. Prvisin f data capture fr clearing and settlement. Additinally Entry Pint and Kernels C-1 t C-7 shall be lcated in the POS System. The physical architecture f the POS System can be any f the fllwing, accrding t Bk A definitin: Fully integrated terminal FIT : All elements included in a single device. Intelligent card reader ICR : The reader handles mst f the cntactless

15 Type Apprval Overview Page 9 / 78 transactin prcessing, passing the results fr cmpletin by the terminal. Cmbinatin f terminal and transparent card reader: The reader prvides cmmunicatin with the card, while kernels and ther prcesses are in the terminal. Nte: The Terminal described in these belw definitins can be any physical device such as a POS, an ATM, a PIN PAD, etc... 1/ Fully Integrated Terminal (FIT): All elements f POS System included in a single device. Figure 1: Fully Integrated Terminal The FIT includes: A valid Level 1 Cntactless PCD with an EMVC Letter f Apprval accrding t Bk D. Entry Pint and POS System Architecture accrding t Bk A and B EMV Kernels accrding t Bk C-1 t C-7 including (refer t nte belw): Kernel transactins flw, Kernel functins, EMV data management, Cryptgraphy,. Cnsumer & merchant interface(s). If present, the cntact and mag stripe part f the FIT: IFM (L1), EMV cntact Kernel (L2). Acquiring Netwrk interface. In this definitin, the Fully Integrated Terminal and POS System are identical and cntain the Prduct. 2/ Intelligent Card Reader (ICR), the reader handles mst f the cntactless transactin

16 Type Apprval Overview Page 10 / 78 prcessing, transmitting the results fr cmpletin t the terminal. scenaris are pssible: Tw implementatin Single Cmpnent ICR (S-ICR): First scenari, where all EMV cmpnents (EMV requirements defined in Bk A, B, C and D) are in the reader. The Prduct submitted fr apprval will be the reader alne: Figure 2: Single Cmpnent ICR (example 1)

17 Type Apprval Overview Page 11 / 78 Figure 3: Single Cmpnent ICR (example 2) The ICR includes: A valid Level 1 Cntactless PCD with an EMVC Letter f Apprval accrding t Bk D. Entry Pint and POS System Architecture accrding t Bk A and B. EMV Kernels accrding t Bk C-1 t C-7 including (refer t nte belw): Kernel transactins flw, Kernel functins, EMV data management, Cryptgraphy,. If present, the cntact part f the ICR: IFM (L1), EMV cntact Kernel (L2). In this definitin, the Intelligent Card Reader and Prduct are identical and are part f the POS System. Nte: if present, the Cntact part can reside either in the Terminal r in the ICR [See Figure 2 & 3]. Multi Cmpnent ICR (M-ICR): Secnd scenari, where mst f the EMV cmpnents (EMV requirements defined in Bk A, B, C and D) are in the reader. The Prduct submitted fr Apprval will be the reader and the assciated identified Terminal:

18 Type Apprval Overview Page 12 / 78 Figure 4: Multiple Cmpnent ICR (example 1) Figure 5: Multiple Cmpnent ICR (example 2) The ICR includes: A valid Level 1 Cntactless PCD with an EMVC Letter f Apprval accrding t Bk D. Part f Entry Pint and POS System Architecture accrding t Bk A and B. Part f EMV Kernels accrding t Bk C-1 t C-7. If present, the cntact part f the ICR: IFM (L1), EMV Cntact Kernel (L2). In this definitin, the Intelligent Card Reader is part f the Prduct, which is part f the POS System.

19 Type Apprval Overview Page 13 / 78 Nte: if present, the cntact part can reside either in the Terminal r in the ICR [See Figure 4 & 5]. 3/ Cmbinatin f terminal and transparent card reader: The reader prvides cmmunicatin with the card, while kernel and ther prcesses are in the terminal: Figure 6: Transparent Reader Cmbinatin (example 1)

20 Type Apprval Overview Page 14 / 78 Figure 7: Transparent Reader Cmbinatin (example 2) Nte: In case the reader cntains the PCD L1 hardware (analg nly), and, if the PCD L1 Digital sftware is nt present in the reader but in the terminal, then the Prduct is cnsidered as a Fully Integrated Terminal (FIT). Accrding t the abve definitins: a Cntactless Prduct submitted fr apprval shall always include the fllwing: The part f POS System accrding t the abve definitins which include: A valid Level 1 Cntactless PCD with an EMVC Letter f Apprval accrding t Bk D. Entry Pint and POS System Architecture accrding t Bk A and B. EMV Kernels accrding t Bk C-1 t C-7, including (please refer t nte belw): Kernel transactins flw, Kernel functins, EMV data management, Cryptgraphy,. If present, the cntact part f the ICR: IFM, EMV Cntact Kernel. Nte: If a Kernel C-n mdule, r Entry Pint mdule is nt a self-cntaining mdule (fr example using external crypt library), the cmputatin f the Checksum f that Kernel C-n mdule shall include the external library, sub mdules used by this Kernel accrding t annex B.

21 Type Apprval Overview Page 15 / Multi Kernel Envirnment The cntactless Prduct submitted fr apprval wrks in a Multi-Kernel envirnment. This means that ne r several Kernels C-n (C-1 t C-7) are present at the time f testing and will be tested independently. The number f Kernels (C-1 t C-7) present in the Prduct fr apprval depends n the Prduct Prvider s decisin. He may decide t submit a Prduct cntaining ne Kernel (as a minimum) r up t 7 Kernels fr apprval. Apprval will be granted t the crrespnding Prduct and is valid nly fr that cnfiguratin reflecting the specific Kernel(s) present during apprval. A Prduct Prvider can decide at anytime t enhance the Prduct by adding/deleting/changing a Kernel (r Entry Pint). Hwever this shall result in a new apprval if required t that Prduct, reflecting the new Prduct. When the Prduct cntains als the Cntact EMV Kernel, apprval will be granted n the verall Prduct cvering cntact and cntactless in a single LA. When the Prduct cntains any sftware r kernel nt described by EMVC and changes ccur t such sftware, it is cnsidered as a change t the Prduct, hence, sectin 8 changes applies Mdular Apprach Principles EMVC will cnsider tw Type Apprval prcesses fr cntactless Prducts depending n the sftware implementatin: Optimized Prcess fr Prducts using the Mdular Architecture accrding t [TA Archi], where the Prduct is cnsidered cmpliant t the Mdular Architecture by EMVC. Standard Prcess fr all ther implementatins. A Prduct Prvider claiming that his Prduct fllws the Mdular Architecture needs t perfrm the Cmpliance audit as the first stage f the prcess. The gal f this Cmpliance audit is t ensure that the Prduct submitted cmplies with the EMVC Mdular Architecture requirements with a Prduct Prvider Mdular Architecture audit, perfrmed by an EMVC Qualified Auditr. (see [TA Archi] fr further details). The psitive result f this audit is a Mdular Label (ML) f the Mdular Architecture implemented in the Prduct submitted fr apprval. This Mdular Label is valid fr all Prducts submitted by the Prduct Prvider implementing identical Mdular Architecture, therefre, several prducts may be submitted fr apprval using the same Mdular Label, as lng as these prducts implement the same Mdular Architecture.

22 Type Apprval Overview Page 16 / EMVC Cntactless Type Apprvals Descriptin Standard Prcess fr Cntactless Type Apprval The fllwing rules shall apply t Prducts submitted t EMVC fr frmal apprval when the Prduct des nt implement Mdular Architecture. These rules d nt apply t debug testing that may be cnducted directly between the Labratry and Prduct Prvider. All functinal ptins, L1 Apprved PCD and Kernels (C-1 t C-7 and Prprietary kernels) must be identified n the ICS t reflect the Prduct cnfiguratin submitted fr apprval. The labratry must validate and submit a cpy f the cmpleted ICS t EMVC prir t perfrming type apprval testing. EMVC will review the statement fr accuracy, archive the frm fr later cmparisn, and send an acknwledgement that the ICS is acceptable fr testing. If a cntact EMV Kernel is present in the Prduct and changes made t the Prduct, then the cmplete Prduct shall be retested (bth cntact and cntactless). When the Prduct cntains any ther sftware r kernel nt describes by EMVC, if any changes t such sftware ccur, then this is cnsidered as a change t the Prduct, and the cmplete Prduct shall be retested (bth cntact and cntactless). Apprved Prducts are retained by the Labratry fr a perid f 4 years as f the date f apprval. The Prduct Prvider is respnsible fr prviding supprt as necessary t maintain the prduct in an peratinal state t accmmdate any subsequent testing r analysis that may be deemed necessary by EMVC Request f Apprval EMVC assesses cmpliance f the Prduct design against the EMV Cntactless Specificatins and Type Apprval requirements. T determine cnfrmance, reference implementatins f the Prduct must underg predefined tests in a specified test envirnment (EMVC Accredited Labratry). The Prduct submitted t Labratry shall be submitted with a Cntactless Level 1 (PCD) cmplete with valid LA and must be representative f final deplyment. The Letter f Apprval will be granted n the cmplete Prduct (including the hardware, and the cntact LAs if applicable). After the Letter f Apprval has been granted, it remains valid as lng as the fllwing applies: The apprval is nt revked by EMVC. The LA is valid fr the perid f apprval duratin. Any change t the Prduct creates a new Prduct, whether it ccurs befre, during, r after deplyment. Type Apprval f that new Prduct is nt presumed. Nte: It is assumed that if cntact is present in the Prduct, the Cntact LA has been granted previusly r in parallel.

23 Type Apprval Overview Page 17 / Renewal Request fr Apprval A Prduct apprval is valid fr 3 years. The starting date is the date f the initial apprval. Every 3 years, EMVC evaluates whether the prduct demnstrates sufficient cmpliance t the current EMV Cntactless Specificatins. If the evaluatin results are psitive then EMVC grants an extensin t the Prduct Letter f Apprval. The fllwing rules will be applied t Renewal Requests: The Prduct n ging LA is still valid at the time f renewal. The Level 1 LA must be valid at the time f renewal. The cntact L1, L2 LAs are still valid at the time f renewal (if cntact is present in the Prduct). All EMV Cntactless Specificatins are still valid ([Bk A], [Bk B] and [Bk C- n]). All EMV Cntact Specificatins are still valid (Bk [N1] [N2] [N3] and [N4]) (if cntact is present in the Prduct). After the renewal date, prducts nt passing renewal testing nr applied fr renewal testing will be remved frm the apprved list and their Letter f Apprval will be cnsidered revked Labratry testing prcedure fr Standard Prcess Testing prcedure fr apprval: Labratries perfrm testing f Prducts under the fllwing rules, fr each testing sessin: Bk A & Bk B testing using [TA A&B] test plan. Kernels C-1 t C-7 testing fr all Kernels declared in the ICS and present in the Prduct submitted. The testing is perfrmed using the independent test plans related t the kernels C-1 t C-7 (Kernels present maybe tested ver several labratries as described in sectin and ). Kernel testing cvers tw parts fr each Kernel: - Kernel functinal testing (ne test plan per Kernel) using [TA C-n], - Perfrmance testing (ne test plan per Kernel) using [TA P]. Multi-Kernel Independency testing as described in [TA M], where nly the independency test set applies (n mdular testing). This set f tests ensures that there is n crruptin between Kernels present in the Prduct. Testing prcedure fr renewal Labratries shall perfrm renewal testing f Prducts under the fllwing rules: Delta testing f each mdule present (Bk A & Bk B, kernels C-1 t C-7): perfrming the delta tests (used test plans vs latest test plans available). Regressin testing f each mdule present (Bk A & Bk B, kernels C-1 t C-7): perfrming tests frm the latest test plans available. Independency full testing. If needed, renewal rules fr the cntact regressin applies. Labratry shall cnfirm that the Checksum(s) are identical with the previusly apprved Prduct.

24 Type Apprval Overview Page 18 / 78 Transactin Type Testing: Sectin IV f the Cntactless Prduct ICS, requests the transactin type(s) supprted and activated fr each Kernel present in the Cntactless Prduct. When a transactin type is supprted and activated at a kernel level then it is cnsidered supprted and activated at the prduct level and the related tests shall be executed. Example: Prduct cntains: C-1 which supprts Purchase and C-2 which supprts and activates Purchase and Refund : Bk A & Bk B (Entry Pint) testing using [TA A&B] test plan perfrms all applicable tests with Purchase and Refund (eg: 2EA applies) Kernel C-1 using [TA C-1] and using [TA P] perfrms all tests with Purchase (if tests cntain this ptin). Kernel C-2 using [TA C-2] and using [TA P] perfrms all applicable tests Multi-Kernel Independency testing using [TA M] perfrms Fr C-1 all tests with Purchase Fr C-2 all tests with Purchase and all tests with Refund Nte 1: all steps abve must be run n the final sftware mdule versins fr the apprval testing prcedure. If any failures ccur, then the whle set f tests must be re-run until a successful cmpletin is achieved. Nte 2: all steps abve fr renewal testing must be run n the already apprved prduct. Nte 3: Checksum values f each mdule and sub mdules; as well as untested mdules, shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value declared by the Prduct Prvider. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct. Nte 4: When the Perfrmance testing is applicable, the Prduct Prvider shall at the same time cmplete the Perfrmance declarative frm and prvide it t EMVC. Nte 5: Supprt and Activatin f the transactin type implementatin depends n each Kernel, fr example fr C-3 if the transactin type is supprted it is autmatically activated Optimized Prcess fr Cntactless Type Apprval Cmpliance Audit Fr submissin f Prducts fllwing a Mdular Architecture a Cmpliance Audit is required. Any Prduct claiming t actualize this Mdular Architecture shall apply the fllwing rules as the first stage f the Type Apprval prcess (r in parallel f the Initial submissin): Select an EMVC qualified Auditr Submit t the Auditr all required dcumentatin n the Prduct s Mdular Architecture. Internal Prduct Prvider testing dcuments are required. Auditr perfrms the audit based n: The dcumentatin received, On-site visit f the Prduct Prvider develpment capabilities, Auditr returns the results back t the Prduct Prvider. Prduct Prvider verifies the audit reprt prvided by Auditr

25 Type Apprval Overview Page 19 / 78 Prduct Prvider and Auditr sign the audit reprt results. Prduct Prvider submits a Request fr Cmpliancy t EMVC. Prduct Prvider prvides the signed audit reprt t EMVC. EMVC will review the statement fr accuracy, and the results f the audit. If the results are cnsidered as acceptable, EMVC will issue a Mdular Label (ML) reflecting the Mdular Architecture audited. This ML is valid fr all Prducts implementing identical Mdular Architecture. Nte: At the time f Request f Cmpliance submissin, the Prduct Prvider shall be registered with EMVC. A Mdular Architecture Cmpliance is valid fr 5 years Initial Prduct Submissin The fllwing rules shall be applied t Prducts initially submitted t EMVC fr frmal apprval when the Prduct implements a Mdular Architecture. These rules d nt apply t debug testing that may be cnducted directly between the Labratry and Prduct Prvider. All functinal ptins, L1 Apprved PCD and Kernels present must be identified n the ICS (including Cntact if present). This reflects the Prduct cnfiguratin submitted fr apprval. A Valid Mdular Label reflecting the Mdular Architecture f the Prduct shall be identified n the ICS, r prvided later during the Type Apprval reprt review. In any case, this ML must be available befre LA issuance. The labratry must validate and submit a cpy f the cmpleted ICS t EMVC prir t perfrming type apprval testing. EMVC will review the statement fr accuracy, archive the frm fr later cmparisn, and send an acknwledgement that the ICS is acceptable fr testing. Apprved Prducts are retained by the Labratry fr a perid f 4 years as f the date f apprval. The Prduct Prvider is respnsible fr prviding supprt as necessary t maintain the prduct in an peratinal state t accmmdate any subsequent testing r analysis that may be deemed necessary by EMVC. Nte: It is assumed that if cntact is present in the Prduct, the Cntact Type Apprval has been granted previusly r in parallel Subsequent Prduct Submissin The fllwing rules shall be applied t Prducts actuating Mdular Architecture submitted t EMVC fr subsequent frmal apprval: Subsequent Submissin shall be based n the riginal hardware cnfiguratin (L1 apprved PCD, FIT, ICR r Transparent Reader cnfiguratin and cntact IFM). Mdular Label shall be cmpatible with the Initial Submissin and with the Mdular Architecture submitted fr apprval. Any added Kernels, EMV r prprietary, must be identified n the ICS (if applicable). This reflects the Additinal Prduct cnfiguratin submitted fr apprval. A new Letter f Apprval will be issued related t this Prduct cnfiguratin. Mdified Entry Pint mdule r mdified Kernels must be identified n the ICS (if applicable). This reflects the same Prduct cnfiguratin submitted fr Apprval. An

26 Type Apprval Overview Page 20 / 78 updated Letter f Apprval will be issued related t this Prduct cnfiguratin update. The labratry must validate and submit a cpy f the cmpleted ICS t EMVC prir t perfrming type apprval testing. EMVC will review the statement fr accuracy, archive the frm fr later cmparisn, and send an acknwledgement that the ICS is acceptable fr testing The Prduct Prvider may decide t perfrm testing n the mdified mdules alne (Mdified Entry Pint mdule r mdified r added Kernel mdules), in which case, the Subsequent Submissin ending date validity remains the same as the Initial Submissin. The Prduct Prvider can als decide t perfrm testing n the mdified mdules alng with delta testing n the nn-mdified mdules against the latest test plan, in which case, the Subsequent Submissin starting date validity starts n the day f apprval f the ICS submitted fr Subsequent Submissin. The belw figures shw examples f Subsequent Submissin: Figure 8: Case where the added/changed mdule nly is tested

27 Type Apprval Overview Page 21 / 78 Figure 9: Case where all mdules are retested (Subsequent Submissin with extended date) Nte: Kernels C-a, C-b r C-c f the figures refer t C-1 t C-7 Kernels nly as examples. Apprved Prducts are retained by the Labratry fr a perid f 4 years as f the date f apprval. The Prduct Prvider is respnsible fr prviding supprt as necessary t maintain the prduct in an peratinal state t accmmdate any subsequent testing r analysis that may be deemed necessary by EMVC Request fr Mdular Cmpliance EMVC assesses cmpliance f the Mdular Architecture design f the Prduct against the EMV Type Apprval Requirements fr Mdular Implementatin ([TA Archi]). T determine cmpliance, Mdular Architecture that will be implemented in the Prduct must underg design Mdular Architecture audit. The Mdular Label will be granted t the Mdular Architecture, which can be implemented in any Prduct submitted fr apprval by the Prduct Prvider. After the Mdular Label has been granted, it is valid as lng as the fllwing applies: The Mdular Architecture design audited is the same as it was within the samples f the Prduct, which were tested and apprved. The Cmpliance is nt revked by EMVC. The ML has nt expired Request f Apprval T determine cmpliance, reference implementatins f the Prduct must underg predefined tests in a specified test envirnment (Labratry). The Prduct submitted t Labratry shall be submitted with a Cntactless Level 1 (PCD)

28 Type Apprval Overview Page 22 / 78 cmplete with a valid LA and must be representative f final deplyment. The Letter f Apprval will be granted n the cmplete Prduct (including the hardware, the Mdular Architecture and the cntact LA if applicable). After the Letter f Apprval has been granted, it is valid as lng as the fllwing applies: The apprval is nt revked by EMVC. The LA is valid fr the perid f apprval duratin Any change t the Prduct design may create a new Prduct, whether it ccurs befre, during, r after deplyment. Type Apprval f that new Prduct is nt presumed Renewal Request fr Apprval A Prduct apprval is valid fr 3 years. The starting date is the date f the initial apprval r the date f the subsequent apprval (date depends if the subsequent apprval were perfrmed with r withut delta testing). Every 3 years, EMVC evaluates whether the prduct demnstrates sufficient cmpliance t the current EMV Cntactless Specificatins. If the evaluatin results are psitive then EMVC grants an extensin t the Prduct Letter f Apprval. The fllwing rules will apply t Renewal Request: The Prduct' nging LA is still valid at the time f renewal. The Level 1 LA f all IFM(s) listed in the Prduct must be valid at the time f renewal. In case sme IFM(s) LA are n mre valid, these cncerned IFM will be remved frm the renewed Cntactless Prduct LA. The cntact L1, L2 LAs are still valid at the time f renewal (if cntact is present in the Prduct). In case sme PCD(s) LA are n mre valid, these cncerned PCD will be remved frm the renewed Cntactless Prduct LA. All EMV Cntactless Specificatins are still valid (Bk A, B and C-n) All EMV Cntact Specificatins are still valid (Bk N1 N2 N3 N4) (if cntact is present in the Prduct) After the renewal date, Prducts nt passing renewal testing nr applying fr renewal testing will be remved frm the apprved list and their Letter f Apprval will be cnsidered revked Labratries testing prcedure fr Optimized Prcess The fllwing test sessins must be run fr initial submissin in this rder: Labratries shall perfrm testing f Prducts under the fllwing rules, fr each initial testing sessin: Bk A & Bk B testing using [TA A&B] test plan. Kernels C-1 t C-7 testing fr all Kernels declared in the ICS and present in the Prduct submitted. The testing is perfrmed using the independent test plans related t the kernels C-1 t C-7. Kernel testing cvers tw parts fr each Kernel: - Kernel functinal testing (ne test plan per Kernel) using [TA C-n], - Perfrmance testing (ne test plan per Kernel) using [TA P].

29 Type Apprval Overview Page 23 / 78 Multi-Kernel Independency testing using [TA M], where the independency test set applies. This set f tests ensures that there is n crruptin between Kernels present in the Prduct. Mdular testing using [TA M], where the mdular test set applies. This set f tests ensures that Mdular Architecture is crrectly implemented in the Prduct. Nte 1: all steps abve must be run n the final sftware mdule versins. If any failures ccur in a Mdule (Kernel r Bk A & B), then the whle set f tests f the cncerned Mdule (Kernel r Bk A &B) must be re-run until a successful cmpletin is achieved. If the successful cmpletin f a Kernel testing cannt be achieved, but the Bk A & B and the ther Kernel pass successfully the testing (included Mdular, Independency and perfrmance) withut any change in the final sftware versins, then the LA can be issued withut the cncerned Kernel. Nte 2: Checksum values f each mdule and sub mdules; as well as untested mdules, shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value declared by the Prduct Prvider. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct Nte 3: If the mdular testing fails during the initial submissin the Prduct can still be apprved, but it cannt g thrugh Optimized Prcess fr subsequent apprval, (n reference in the LA t the ML). Nte 4: If testing can n The fllwing test sessins must be run fr subsequent apprval in this rder: Labratries shall perfrm testing f Prducts under the fllwing rules, fr each testing sessin: Bk A & Bk B (Entry Pint) testing using [TA A&B] test plan nly when the Entry Pint mdule has been mdified. Kernels C-1 t C-7 using [TA C-n] and using [TA P] fr thse added r mdified Kernels declared in the ICS. Multi-Kernel Independency testing using [TA M], where the independency test set applies. This set f test ensures that there is n crruptin between Kernels present in the Prduct. Mdular testing using [TA M], where the mdular test set applies. This set f tests ensures that Mdular Architecture is crrectly implemented in the Prduct. Nte 1: all steps abve must be run n the final sftware mdule versins. If any failures ccur in a Mdule (Kernel r Bk A & B), then the whle set f tests f the cncerned Mdule (Kernel r Bk A &B) must be re-run until a successful cmpletin is achieved. If the successful cmpletin f a Kernel testing cannt be achieved, but the Bk A & B and the ther Kernel pass successfully the testing (included Mdular, Independency and perfrmance) withut any change in the final sftware versins, then the LA can be issued withut the cncerned Kernel. Nte 2: Checksum values f each mdule and sub mdules; as well as untested mdules, shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value declared by the Prduct Prvider. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct. The fllwing test sessins must be run fr Renewal apprval:

30 Type Apprval Overview Page 24 / 78 Labratries shall perfrm renewal testing f Prducts under the fllwing rules: Delta testing f each mdule present (Bk A & Bk B, kernels C-1 t C-7): perfrming the delta tests (used test plans vs latest test plans available). Regressin testing f each mdule present (Bk A & Bk B, kernels C-1 t C-7): perfrming tests frm the latest test plans available. Mdular full testing. Independency full testing. If needed, renewal rules fr the cntact regressin applies. Labratry shall cnfirm that the Checksum(s) are identical with the previusly apprved Prduct. Nte 1: all steps abve must be run n the final sftware mdule versins. If any failures ccur in a Mdule (Kernel r Bk A & B), then the whle set f tests f the cncerned Mdule (Kernel r Bk A &B) must be re-run until a successful cmpletin is achieved. Nte 2: all steps abve fr renewal testing must be run n the already apprved prduct. Nte 3: Checksum values f each mdules and sub mdules; as well as untested mdules, shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value declared by the Prduct Prvider. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct. Transactin Type Testing: Sectin IV f the Cntactless Prduct ICS, requests the transactin type(s) supprted and activated fr each Kernel present in the Cntactless Prduct. When a transactin type is supprted and activated at a kernel level then it is cnsidered supprted and activated at the prduct level and the related tests shall be executed. Example: Prduct cntains: C-1 which supprts Purchase and C-2 which supprts and activates Purchase and Refund : Bk A & Bk B (Entry Pint) testing using [TA A&B] test plan perfrms all applicable tests with Purchase and Refund (eg: 2EA applies) Kernel C-1 using [TA C-1] and using [TA P] perfrms all tests with Purchase (if tests cntain this ptin). Kernel C-2 using [TA C-2] and using [TA P] perfrms all applicable tests Multi-Kernel Independency testing using [TA M] perfrms Fr C-1 all tests with Purchase Fr C-2 all tests with Purchase and all tests with Refund Nte: Supprt and Activatin f the transactin type implementatin depends n each Kernel, fr example fr C-3 if the transactin type is supprted it is autmatically activated. 2.3 Cntactless Type Apprval Life Cycle Cncept The fllwing sectins identify the type apprval life cycle which is a lgical cncept

31 Type Apprval Overview Page 25 / 78 regarding the design and key apprval milestnes f a Cntactless Prduct Cntactless Prduct Life Cycle and Type Apprval Milestnes Type Apprval shall be dne n a sample that is representative f future prductin. Therefre, the Type Apprval milestne shall ccur at a particular mment in the Prduct Life cycle: (Figure 10). Figure 10: Life cycle f Cntactless Prduct Prduct Design Phase The Prduct is develped by the Prduct Prvider r an entity directly related t the Prduct Prvider. Mst imprtantly, Prduct design and develpment must be in accrdance with the EMV Cntactless Specificatins, as well as any ther applicable specificatins (e.g. gvernment standards) Prduct Debugging Phase The Prduct design is checked and tested against all related specificatins. EMVC recmmends that cmpliance testing against the EMV Cntactless Specificatins is cnducted n the representative sample befre prceeding t type apprval, preferably with tls equivalent t thse used fr type apprval tests. The Prduct Prvider must identify which ptins its Prduct design has incrprated frm the EMV Cntactless Specificatins and gather the infrmatin t be submitted in the Type Apprval prcess Prduct Apprval Phase EMVC assesses cmpliance (see sectin & ) f the Prduct design against the EMV Cntactless Specificatins. T determine cmpliance, reference implementatins f the Prduct must underg predefined tests in a specified test envirnment (EMVC Accredited Labratry). The Prduct submitted fr apprval shall be cmplete with a valid EMVC Level 1 Letter f Apprval and must be representative f final deplyment. In case f applying fr Optimized Prcess, the prduct submitted fr apprval shall als

32 Type Apprval Overview Page 26 / 78 wn a valid EMVC Mdular Label. After the Letter f Apprval has been granted, it is valid as lng as the fllwing applies: The apprval is nt revked by EMVC. The LA is valid fr the perid f apprval duratin. Any change t the Prduct creates a new Prduct, whether it ccurs befre, during, r after deplyment. Type Apprval f that new Prduct is nt presumed. Subsequent Submissin Apprval At any time during the Prduct Apprval Phase fr Optimized Prcess, the Prduct Prvider may decide t add r mdify a sftware mdule such as a Kernel, when the Prduct cmplies with a Mdular Architecture (see sectin ). This will result in an additinal apprval called Subsequent Submissin. Depending n the mdule mdified r added, different predefined tests will be run fr this Subsequent Submissin, and will result in an update f the Letter f Apprval Prduct Apprval Renewal Phase Prir t the renewal date, Prduct Prviders may request a renewal by submitting the riginal apprved prduct t EMVC fr Renewal testing (see sectins & ). The purpse f this renewal testing is t ensure that prducts pass the mst current EMVC testing. At the time f submissin, the prduct submitted fr apprval shall be cmplete with valid EMVC Level 1 Letter f Apprval. In case f applying fr Optimized Prcess, the Prduct submitted fr apprval shall als wn a valid Mdular Label.

33 Type Apprval Overview Page 27 / ICS Submissin rules ICS Submissin The initial ICS submissin t the EMVC is free f charge. The ICS submitted must be the ICS in pdf frmat, capable f imprting/exprting XML frmat and shall be digitally signed by the Prduct Prvider and the Labratry at the time f submissin t EMVC. The Labratry supplies the signed cpy f the vendr-supplied ICS t EMVC fr review prir t the start f the type apprval testing prcess. EMVC will review and apprve the ICS by returning the ICS in pdf digitally signed and with the fficial ICS number. In case the ICS is incrrectly filled, decline fee applies t Labratry ICS replacement One free ICS replacement is allwed during the ICS life cycle. Any subsequent ICS replacement requested will be charged t the Prduct Prvider. Same submissin prcess applies as fr initial ICS submissin (Labratry submits the changed ICS). This applies t any change in the ICS after the fficial apprval f the ICS by EMVC. After the start f the test sessin f the Prduct, ICS replacements (fllwing the rules f the previus bullet) are nly allwed fr administrative infrmatin update (such as name f prduct) but nt are nt allwed fr technical infrmatin update. Labratry shall ensure that any ICS change requested is nt made t hide a bug in the prduct (such as deactivatin a functin because this functin is nt wrking prperly). ICS replacement is n mre allwed after Test Reprt submissin t EMVC. Nte: ICS decline prcess remains and any errr reprted by EMVC will be charged t the Labratry (as Labratry is respnsible f reviewing the ICS prvided by the Prduct Prvider). ICS decline prcess applies t the initial ICS submissin and als t any ther ICS replacement (charged r nt charged t the Prduct Prvider).

34 Type Apprval Overview Page 28 / EMVC type apprval fee structure Fees structure fr Standard Prcess The fllwing fee structure applies fr Standard Prcess : Submissin ICS Replacement (starting at 2 nd Replacement) Prduct renewal Declined ICS/Reprt LA reissuance Fees structure fr Optimized Prcess The fllwing fee structure applies fr Optimized Prcess : Mdular Label Initial submissin Subsequent submissin Subsequent submissin with extended date ICS Replacement (starting at 2 nd Replacement) Derivative Prduct submissin: Prduct renewal Declined ICS/Reprt LA reissuance Nte: The amunt f each fees are published in Terminal Type Apprval Bulletin 185.

35 Rles & Respnsibilities Page 29 / 78 3 Rles & Respnsibilities The fllwing sectins define the rles and respnsibilities f the varius participants in the type apprval prcess. 3.1 EMVC EMVC defines type apprval cntactless requirements and evaluates peratinal results. EMVC prvides the fllwing services: Defines the Administrative Prcess. Operates the Apprval Prcess. Defines mandatry auditr qualificatin requirements. Qualifies cmpanies that perfrm audits t establish Labratry accreditatin. Qualifies cmpanies that perfrm audits t establish Mdular Architecture cmpliance. Defines Labratry accreditatin requirements. Evaluates Labratry audit results and determines if the EMVC accreditatin shuld be granted t a Labratry. Defines Tl Qualificatin Prcess. Qualifies Test Tl and maintains a list f Qualified Test Tls n the EMVC web site. Crdinates with the Payment Systems fr the Kernels C-n testing. Manages Labratry appeals prcess and reslves accreditatin disputes. Manages Prduct Prvider s appeals prcess and reslves Mdular Architecture cmpliance disputes. Defines apprpriate test cases t test cmpliance with EMVC Cntactless Specificatins. Defines prcedures used t perfrm testing, submits test results fr evaluatin, and cmmunicates evaluatin results. Defines the test tls and evaluatin criteria theref. Evaluates Mdular Architecture audit results and determines if the EMVC cmpliance f that architecture shuld be granted. Evaluates Prduct apprval test results t determine whether apprval shuld be granted. Evaluates Prduct renewal tests results t determine whether a renewal shuld be granted. Ntifies apprpriate EMVC wrking grup f warranted specificatin crrectins, clarificatins, and enhancements where apprpriate. Evaluates terminal and card failure cmplaints t determine if type apprval revcatin fr a particular Prduct is apprpriate.

36 Rles & Respnsibilities Page 30 / 78 Prvides result respnse t Prduct Prvider s type apprval test result evaluatin request. Maintains and publishes (via EMVC web-site) a list f Prducts that have received EMVC type apprval ntificatin. Issue the Letter f Apprval. Issue the Mdular Label. 3.2 EMVC Type Apprval Secretariat (CATA) The EMVC Terminal Type Apprval Secretariat (CATA Secretariat) is respnsible fr managing the EMVC Type Apprval cntactless prcess. This includes the administrative functins assciated with Prduct Prvider s registratin, cmpletin f cntracts, prcessing apprval requests and fees, issuing letters f apprval letters f cmpliance r decline, etc. The rle als includes cmmunicating type apprval status t third parties and the maintenance f a database that prvides the fllwing: Crdinate with the Payment Systems. Qualified Auditrs. Accredited Labratries. Qualified EMVC Tls. Type apprval and cmpliance requirements and test cases. Apprved EMV cntact & cntactless Prducts. 3.3 Auditrs Tw types f auditrs are required fr cntactless prcess: Labratry Auditr: The Labratry Auditr is in charge f auditing the Labratry fr accreditatin purpse. Cmpliance Auditr: The Cmpliance Auditr is in charge f auditing the Mdular Architecture prvided by the Prduct Prvider, checking the cmpliance f the Prduct Mdular Architecture with EMVC Mdular Requirements (see dcument [TA Archi]). He als prvides the signed audit reprt t EMVC when apprved by the Prduct Prvider. 3.4 EMVC Accredited Labratries The Labratry is a test facility accredited by EMVC t cnduct testing f the Prduct r part f the Prduct in accrdance with the EMVC type apprval requirements and test cases. It shall als: Verify the Implementatin Cnfrmance Statement prvided by the Prduct Prvider

37 Rles & Respnsibilities Page 31 / 78 Extract the set f test case depending n: The versin f Entry Pint, The versin f each Kernel, If the Prduct Prvider wants t prceed t Standard Prcess r Optimized Prcess, If it is an initial r subsequent submissin (case f Optimized Prcess nly), If it is a renewal apprval. Perfrm the test sessin Checksum values f each mdule and sub mdules; as well as untested mdules shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value declared by the Prduct Prvider. Analyze the test results. Cmmunicate the results t the Prduct Prvider. Send t EMVC the result f the test sessin(s) after Prduct Prvider apprval. Eventually send the Request fr Apprval n behalf f the Prduct Prvider. 3.5 Prduct Prvider Mdular Cmpliance Request The Prduct Prvider shall Sign apprpriate cntracts. Select ne Auditr t perfrm the Audit. Submit t the Auditr the Mdular Architecture dcuments fr review. Verify and apprve the audit reprt prvided by the Auditr. Fill ut the Request fr Cmpliance Frm. Submit t EMVC the Request fr Cmpliance frm Type Apprval Request The Prduct Prvider shall prvide the Prduct t be tested by the Labratry: Sign apprpriate cntracts. Fill ut the Request fr Apprval and Implementatin Cnfrmance Statement Frms. Submit t the Labratry the ICS fr review. Submit t EMVC the Request fr Apprval frm (r the Labratry can submit n behalf f the Prduct Prvider). Select ne r several Labratries t run the tests sessin(s). Submits the final Prduct t the Labratries fr testing. Verify and apprve the test results prvided by the Labratries.

38 Type Apprval Prcedures Page 32 / 78 4 Type Apprval Prcedures The type apprval prcedure applied by Prduct Prviders, Labratries, auditrs and EMVC includes the fllwing: Prduct prvider btains registratin infrmatin frm the EMVC web site r frm an EMVC accredited labratry Prduct prvider submits a cmpleted registratin template t the EMVC Type Apprval Secretariat Prduct prvider btains the Level 2 EMVC/vendr cntract frm EMVC, the EMVC web site r frm an EMVC accredited labratry Prduct Prviders cnclude the cntract with EMVC. This cntract cvers Prduct apprval and Mdular Architecture Cmpliance (if needed). A cntract between EMVC and the Prduct Prviders must be signed befre test results are submitted t EMVC fr evaluatin and ptential type apprval. In case f Optimized Prcess selectin by Prduct Prviders: Prduct Prviders select a Cmpliance Auditr frm the qualified Auditr list published n the EMVC web site, Prduct Prviders cnclude a cntract with the qualified Auditr in respect f the Mdular Architecture t be audited, Prduct Prvider submits relevant dcumentatin t the Auditr, Auditr perfrms the audit, Prduct Prviders validate the audit results, Prduct Prviders submit a cmpleted Request fr Cmpliance frm t EMVC. Based n the Request Fr Cmpliance frm EMVC will prvide Prduct Prvider with an invice, Based n the received invice the Prduct Prvider shall settle the administrative fees with EMVC, Prduct Prviders submit the audit reprt results t the EMVC CATA Secretariat, If the fee payment is cnfirmed by EMVC Financial Secretariat, analysis f the audit reprt results by EMVC and, if apprpriate cmpliance ntificatin. Prduct Prviders select ne r several accredited Labratries frm the list f accredited Labratries published n the EMVC web site. The Labratry perfrming Bk A & B testing, Independency testing and Mdular testing (if Optimized Prcess ) is referenced as the Main Labratry. Prduct Prviders cnclude a cntract with the Labratries selected in respect f the Prduct t be tested. Prduct Prviders and selected Labratries shall fill ut the ICS; ne ICS fr the verall Prduct (called Cntactless Prduct ICS) and ne ICS fr each Kernel C-n present. The Cntactless Prduct ICS is managed by the Main Labratry and it is the respnsibility t share this ICS (after EMVC Apprval f the ICS) with the ther selected Labratries (if any). The Labratry reviews fr accuracy the ICS received frm the Prduct Prvider and then archived fr later cmparisn. Labratries submit a validated cpy f the

39 Type Apprval Prcedures Page 33 / 78 cmpleted ICS t EMVC prir perfrming testing. This ICS must be in pdf frmat, capable f imprting/exprting XML frmat and shall be digitally signed by the Applicatin Prvider and by the Labratry (bth signatures n the same ICS submitted) as paper cpy r scanned cpy are n mre accepted. The EMVC CATA Secretariat will respnd with a cnfirmatin that all the submitted ICSs are acceptable fr testing t the Main Labratry. If the submitted ICS is acceptable the Secretariat respnds back t the Labratry and return at the same time the apprved ICS in.pdf frmat digitally signed If the submitted ICS is unacceptable the Secretariat infrm the Labratry and apply the Decline fees (see Bulletin) All Labratries perfrm apprpriate testing f the submitted Prduct against the published test requirements and test cases. On Prduct Prvider s request, the Labratries submit the ICSs and test results (with checksum f the mdules tested) t the EMVC CATA Secretariat. Prduct Prviders submit a cmpleted Request fr Apprval frm t EMVC. Based n the RFA frm EMVC will prvide Prduct Prvider with an invice. Based n the received invice the Prduct Prvider shall settle the administrative fees with EMVC. If the fee payment is cnfirmed by EMVC Financial Secretariat, analysis f the ICS and test results by EMVC will start and, if apprpriate, apprval ntified. Type apprved cntactless Prducts are psted n the EMVC web site after apprval ntificatin. Apprved prducts are retained by the Labratry fr a perid f 4 years as f the date f apprval. The Prduct Prvider is respnsible fr prviding supprt as necessary t maintain the Prduct in an peratinal state t accmmdate any subsequent testing r analysis that may be deemed necessary by EMVC. Figure 11 belw shws the diagram f Type Apprval Prcesses

40 Type Apprval Prcedures Page 34 / 78 Figure 11: Cntactless Prduct Type Apprval Prcedure

41 Type Apprval Prcedures Page 35 / 78

42 Type Apprval Prcedures Page 36 / Registratin Registratin prvides the Prduct Prvider with entry t the EMVC apprval prcess in rder t make the Prduct Prvider aware f all frmalities that need t be finalized prir t submitting their final test reprt t EMVC fr apprval. The registratin prcess is cmpsed f the fllwing steps: The Prduct Prvider submits a registratin request t the EMVC CATA Secretariat. The EMVC CATA Secretariat will send t the Prduct Prvider a respnse with the fllwing: Ø Ø Ø Ø Registratin reference number, Cntract between EMVC and Prduct Prvider, Apprpriate cntact infrmatin, Administrative fees charged fr Type Apprval and payment instructins, 4.2 Cntract with EMVC The Prduct Prvider must cmplete and sign the EMVC defined cntract befre final test results r Mdular Cmpliancy are submitted t EMVC fr evaluatin and pssible apprval. This cntract gverns the relatinship between EMVC and the Prduct Prvider and includes the Prduct Prvider s acceptance f all specificatins, prcedures, terms and cnditins gverning EMVC Cntactless Prduct Type Apprval and Mdular Architecture Cmpliance. The cntract is standard fr all Prduct Prviders t ensure cnsistent requirements fr all participants. Cntract custmizatin fr individual Prduct Prviders is nt pssible. 4.3 Request fr Cmpliance Prduct Prvider and Auditrs This prcedure nly applies when the Prduct Prvider wants t submit prducts with Mdular Architecture t the Optimized Prcess. The Prduct Prvider selects an qualified Cmpliance Auditr frm the EMVC website Once the Cmpliance Auditr is selected, the Prduct Prvider and the Auditr execute a cntract defining the individual rights and bligatins f the cntracting parties. The prvisins f Prduct Prvider/Auditr cntract are up t the cntracting entities and entirely ut f EMVC s scpe. Any fees payable t the Auditr in respect f the audit t be perfrmed are slely at the discretin f the Auditr. The Prduct Prvider submits material t the Auditr in rder fr him t perfrm the audit fr Mdular Architecture Cmpliance. The Auditr perfrms the audit fr Mdular Architecture Cmpliance based n the

43 Type Apprval Prcedures Page 37 / 78 dcumentatin. Auditr submits audit reprt t the Prduct Prvider and bth sign the final audit reprt. The Prduct Prvider submits the final signed audit reprt t EMVC fr review and Cmpliance apprval Prduct Prvider Preparatin fr Cmpliance Request The Prduct Prvider determines whether cmpliance audit reprt resulting frm Auditr will be submitted t EMVC fr evaluatin. Submitting cmpliance audit reprt t EMVC fr evaluatin indicates Prduct Prvider acceptance that the audit reprt is a true representatin f the Mdular Sftware Architecture that will be implemented in the Prducts Prduct Prvider Request fr Cmpliance The request fr review will cmprise: Letter requesting Cmpliance (RFC frm). The cmplete and unchanged Audit reprts f the Mdular sftware Architecture as received frm the Auditr. EMVC invice settled. Any additinal supprting dcumentatin the Prduct Prvider believes is apprpriate EMVC Apprval Upn receiving the request, EMVC will: Review the submitted audit reprts and determine if Mdular Label shuld be granted fr the Mdular Architecture Ntify the Prduct Prvider f Cmpliance apprval r denial fr the Mdular Architecture. Issue Mdular Label, if apprpriate. Prvide ntificatin f EMV Mdular Architecture cmpliance. Mdular Label identifies the Mdular Architectures with the fllwing infrmatin: The Prduct Prvider Mdular Architecture references. 4.4 Request Fr Apprval Prduct Prvider and Labratry Operatins The fllwing peratins are perfrmed by the Prduct Prvider and the Labratry as they relate t the type apprval prcedure: The Prduct Prvider is free t select any EMVC accredited Labratries n purpse f achieving EMVC Cntactless type apprval. A list f accredited Labratries is published n the EMVC web site. Once Labratries have been

44 Type Apprval Prcedures Page 38 / 78 selected, the Prduct Prvider and Labratries sign a cntract defining the rights and bligatins f the cntracting parties. The prvisins f Prduct Prvider/Labratry cntract are up t the cntracting entities and entirely ut f EMVC s scpe. Any fees payable t the Labratry in respect f the tests t be perfrmed are slely at the discretin f the Labratry. In case that the Prduct Prvider has selected multiple Labratries, the Labratry perfrming Bk A & B testing, Independency testing and Mdular testing (fr Optimized Prcess nly) is defined as the Main Labratry fr EMVC. Prduct Prvider sends the apprpriate Implementatin Cnfrmance Statement (ICS) t the chsen Labratry(ies) fr each Prduct that it submits fr testing. The ICS frmat and cntent requirements are determined by EMVC. Each Labratry validates the Prduct Prvider s-supplied ICSs and supplies a cpy t the EMVC CATA Secretariat fr apprval prir t the start f the type apprval testing prcess. The Labratry(ies) tests the Prducts in accrdance with EMVC test prcedures. Tw cases f prcedure can be cnsidered accrding t belw sectin and The Prduct Prvider prepares the Request fr Apprval frm and submits it t the EMVC CATA Secretariat. EMVC then issues the invice t the Prduct Prvider. Prduct Prvider submits payment t EMVC based n the received invice. The Labratry(ies) sends the final test reprts t the Prduct Prvider being the wner f the test results. The Labratry(ies) must advise EMVC f any failures that have been encuntered during testing. The Labratry(ies) submits an riginal cpy f the test results reprt t the EMVC CATA Secretariat, and ensures that the Prduct Prvider has already submitted his cmpleted Request Fr Apprval frm Labratry test prcedure fr Standard Prcess The Labratries must perfrm the fllwing testing prcedure when the test sessin is perfrmed in the Standard Prcess : Fr the Main Labratry: Befre the Test Sessin: Request the Other Labratry(ies) (if any) t prvide the Kernels C-1 t C-7 ICSs they are in charge f. The ICSs prvided by the Other Labratry(ies) t the Main Labratry shall have been previusly apprved by EMVC. When all ICSs f the submitted Cntactless Prduct have been received by the Main Labratry, the Main Labratry sends all ICSs (Cntactless ICS and all Kernels ICSs) t each Other Labratry(ies) invlved in this submissin. During the Test Sessin: Bk A & Bk B testing using [TA A&B] test plan. Kernels C-1 t C-7 testing using the [TA C-n] test plans and [TA P] Test plans: Main Lab shall test ne r several Kernels declared in the ICS and present in the Prduct

45 Type Apprval Prcedures Page 39 / 78 submitted (Main Lab shall test at least test ne f Kernel present). Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing prcess: Verify Independency Tests Pass Criteria nly fr the C kernel(s) the Main Labratry is perfrming test as described in previus paragraph. Verify that Independency Tests pass crrectly (transactins accepted) fr C kernel(s) that the Main Labratry is nt perfrming kernel test (with [TA C-n]). Testing must be dne with the final prduct. This means Labratries must verify the checksum. Checksum values shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against values prvided by the Prduct Prvider in the ICS. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct. Fr the ther Labratry (if any): Befre the Test Sessin: On request frm the Main Labratry, prvide the Kernels C-1 t C-7 ICSs it is in charge f. The ICSs prvided t the Main Labratry shall have been previusly apprved by EMVC. Receive back frm the Main Labratry all ICSs f the submitted Cntactless Prduct. During the Test Sessin: Kernels C-1 t C-7 testing using the [TA C-n] test plans and [TA P] Test plans: Other Lab(s) shall test ne r several Kernels declared in the ICS and present in the Prduct submitted but nt tested by the Main Labratry. Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing prcess: Verify Independency Tests Pass Criteria nly fr the C kernel(s) the Labratry is perfrming test as described in previus paragraph. Verify that Independency Tests pass crrectly (transactins accepted) fr C kernel(s) that the labratry is nt perfrming test (with [TA C-n]). Testing must be dne with the final prduct. This means Labratries must verify the checksum. Checksum values shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against values prvided by the Prduct Prvider in the ICS. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct Nte: A Labratry running a test sessin fr a kernel C-n using related [TA C-n] test plan must run in the same sessin the C-n related perfrmance tests frm [TA-P] test plan Labratry test prcedure fr Optimized Prcess and Initial Submissin The Labratries must perfrm the fllwing testing prcedure when the test sessin is perfrmed in the Optimized Prcess with an Initial prduct Submissin:

46 Type Apprval Prcedures Page 40 / 78 Fr the Main Labratry: Befre the Test Sessin: Request the Other Labratry(ies) (if any) t prvide the Kernels C-1 t C-7 ICSs they are in charge f. The ICSs prvided by the Other Labratry(ies) t the Main Labratry shall have been previusly apprved by EMVC. When all ICSs f the submitted Cntactless Prduct have been received by the Main Labratry, the Main Labratry sends all ICSs (Cntactless ICS and all Kernels ICSs) t each Other Labratry(ies) invlved in this submissin. In the Test Sessin: Bk A & Bk B testing using [TA A&B] test plan. Kernels C-1 t C-7 testing using the [TA C-n] test plans and [TA P] Test plans: Main Lab shall test ne r several Kernels declared in the ICS and present in the Prduct submitted (Main Lab shall test at least test ne f Kernel present). Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing prcess: Verify Independency Tests Pass Criteria nly fr the C kernel(s) the Main Labratry is perfrming test as described in previus paragraph. Verify that Independency Tests pass crrectly (transactins accepted) fr C kernel(s) that the Main Labratry is nt perfrming kernel test (with [TA C-n]). Mdular testing using [TA M], where the mdular test set applies. Testing must be dne with the final prduct. This means Labratries must verify the checksum f each mdule (Entry Pint, Kernels C-n present in the prduct), even fr the mdule(s) nt tested. Checksum values f each mdule and sftware mdule shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against values prvided by the Prduct Prvider in the ICS. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct Fr the Other Labratry (if any): Befre the Test Sessin: On request frm the Main Labratry, prvide the Kernels C-1 t C-7 ICSs it is in charge f. The ICSs prvided t the Main Labratry shall have been previusly apprved by EMVC. Receive back frm the Main Labratry all ICSs f the submitted Cntactless Prduct. During the Test Sessin: Kernels C-1 t C-7 testing using the [TA C-n] test plans and [TA P] Test plans: Other Lab(s) shall test ne r several Kernels declared in the ICS and present in the Prduct submitted but nt tested by the Main Labratry.

47 Type Apprval Prcedures Page 41 / 78 Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing prcess: Verify Independency Tests Pass Criteria nly fr the C kernel(s) the Labratry is perfrming test as described in previus paragraph. Verify that Independency Tests pass crrectly (transactins accepted) fr C kernel(s) that the labratry is nt perfrming test (with [TA C-n]). Testing must be dne with the final prduct. This means Labratries must verify the checksum f each mdule (Entry Pint, Kernels C-n present in the prduct), even fr the mdule(s) nt tested. Checksum values f each mdule and sftware mdule shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against value prvided by the Prduct Prvider in the ICS. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct Nte: A Labratry running a test sessin fr a Kernel C-n using related [TA C-n] test plan must run in the same sessin the C-n related perfrmance tests frm [TA-P] test plan Cntracts between Labratries and Prduct Prvider The prvisins f the cntract entered between Labratries and Prduct Prviders are entirely utside f EMVC s scpe. Hwever, the likely areas fr inclusin are mentined belw fr infrmatin purpses nly: Any Labratry requirements needed fr testing including any sftware applicatin required interfacing with the Labratry test equipment, e.g., hst emulatr, etc. Reference t the cntract between the Prduct Prvider and EMVC. Agreement f mutual cperatin in prviding infrmatin and assistance where needed. Lead-time fr the executin f the type apprval tests. The number f samples available fr testing (At least three shall be prvided). Arrangement fr the preparatin and delivery f samples. Right t keep all samples fr the duratin f the test prcedure. Right t keep all apprved samples fr a perid f the LA validity plus 1 years. Nte: samples are retained fr subsequent testing purpses and the Prduct Prvider must prvide the necessary supprt t the Labratry t ensure the Prduct remains fully functinal. Recgnitin that n infringement n the independence r impartiality f the Labratry will be allwed during r after testing. Agreement n the bundaries f use f the test reprt. Prvisins fr cnflict reslutin Type Apprval Test Reprt The results f the Prduct type apprval tests are cmbined in: ne signed test reprt per Kernel and ne signed reprt fr Bk A & B, Independency and Mdular testing, that are submitted t EMVC in electrnic frmat by each Labratry fr review. The test reprts must include the fllwing infrmatin: Identificatin f the Labratry.

48 Type Apprval Prcedures Page 42 / 78 Identificatin f Prduct Prvider. Identificatin f Prduct. Identificatin f each Kernel mdule tested. Identificatin f Bk A & B testing, Independency testing, Mdular testing (if applicable). Prduct Prvider signed Implementatin Cnfrmance Statement identifying Prduct that has been tested. Fr each mdule tested (kernels, Entry Pint & Bk A) a separate test reprt shall be prvided with the belw infrmatin: Ø Ø Ø Ø EMVC Cntactless Specificatin/test case versin used fr test, Identificatin f all Labratry test equipments and sftware versins used during the tests, Dates tests were perfrmed, The test case executin results in the test reprts fr each test case: EMVC defined test case number and title, Pass, Fail, r Nt Applicable test result, Fr Nt Applicable designated test case results, an explanatin justifying this designatin, Additinal Labratry cmments, if apprpriate, A detailed descriptin f any exceptin test(s) perfrmed r equipment utilized and a descriptin f related test results, A detailed descriptin f the Prduct Prvider s mdificatins that may be required fr the purpse f successfully executing the EMVC test cases Prduct Prvider Preparatin fr Apprval Request The Prduct Prvider determines whether test results resulting frm Labratry testing will be submitted t EMVC fr evaluatin. Submitting test results t EMVC fr evaluatin indicates Prduct Prvider acceptance that the test results are a true representatin f the Prduct. Test results may be submitted t EMVC fr evaluatin up t 90 days frm the date they are generated by the Labratry. Test results lder than 90 days are expired and cannt be submitted fr evaluatin. Prduct re-testing is required t create a current test reprt if the validity perid is exceeded and EMVC evaluatin is desired. The Prduct Prvider must ensure that the Prduct under test assciated with test results submitted t EMVC fr evaluatin remains unaltered and accessible in a timely manner during the evaluatin prcess. It is recmmended that the Prduct under test remain in the pssessin f the Labratry until EMVC has apprved r declined the request fr apprval Prduct Prvider Request fr Apprval The request fr review will cmprise: Letter requesting apprval (RFA frm). The cmplete and unchanged test reprts fr all mdules as received frm the Labratry(ies).

49 Type Apprval Prcedures Page 43 / 78 EMVC invice settled. Any additinal supprting dcumentatin the Prduct Prvider believes is apprpriate EMVC Apprval Upn receiving the request, EMVC will: Review the submitted test reprts and determine if type apprval shuld be granted fr the Prduct Ntify the Prduct Prvider f type apprval r denial fr the Prduct. Issue Letter f Apprval, if apprpriate. Prvide ntificatin f EMV Prduct type apprval. Cntactless Prduct LA identifies the apprved prduct with the fllwing infrmatin: The apprved Kernel names, versin and checksum(s). The apprved Level 1 PCD f the prduct. The hardware cnfiguratin f the prduct (FIT, ICR r Transparent Reader Cmbinatin). The apprved Level 1 Cntact IFM (if present). The apprved Level 2 Cntact Kernel (if present). The EMV Cntactless Specificatins versin against which it was tested. The Test Plan(s) versin against which it was tested. The list f apprval numbers fr the different tested features. The renewal date. Nte: Checksums identified n the LA are the Kernel(s) and Entry Pint Checksums nly. Sftware mdule will nt be identified n the LA. Nte 2: Fr Optimised Prcess nly: If the successful cmpletin f a Kernel testing is nt achieved, but the Bk A & B and the ther Kernel pass successfully the testing (included Mdular, Independency and perfrmance) withut any change in the final sftware versins, then the LA can be issued withut the cncerned Kernel Intermediate Letter f Apprval In given situatins the review f Test reprt frm specific kernel(s) may take lnger then expected and culd slw dne the issuance f the Letter f Apprval. In such cases, EMVC will infrm the Prduct Prvider which can decide t issue an intermediate Letter f Apprval cvering: The already apprved Kernel names, versin and checksum(s). The apprved Level 1 PCD f the prduct. The hardware cnfiguratin f the prduct (FIT, ICR r Transparent Reader Cmbinatin). The apprved Level 1 Cntact IFM (if present).

50 Type Apprval Prcedures Page 44 / 78 The apprved Level 2 Cntact Kernel (if present). The EMV Cntactless Specificatins versin against which it was tested. The Test Plan(s) versin against which it was tested. The list f apprval numbers fr the different tested features. The renewal date. Final Letter f Apprval, cvering all kernels f the submitted Cntactless Prduct, will be issued autmatically by EMVC after the review f the test reprts f the cncerned kernel(s) Optimized Prcess and Subsequent Submissin: Labratry Testing Prcedure Kernel Additin, Change n Kernel r n Entry Pint The Labratries must perfrm the fllwing testing prcedure when the test sessin is perfrmed with the Optimized Prcess during a Subsequent Submissin f the Prduct. This prcedure applies t all Subsequent Submissins: fr Kernel additin r any change in any f the mdule present (EP r Kernel): Bk A & Bk B testing using [TA A&B] test plan if a change has been made in this mdule. Kernels C-1 t C-7 testing nly fr Kernels declared in the ICS as changed r added using the [TA C-n] test plans and [TA P] Test plans. Additinally the belw test plans must always be run fr Subsequent Submissin: Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing prcess: Verify Independency Tests Pass Criteria nly fr the C kernel(s) the Labratry is perfrming test as described in previus paragraph. Verify that Independency Tests pass crrectly (transactins accepted) fr C kernel(s) that the labratry is nt perfrming test (with [TA C-n]). Mdular testing using [TA M], where the mdular test set applies. Testing must be dne with the final Prduct. This means Labratries must verify the Checksum f each mdule (Entry Pint, Kernels C-n present in the Prduct), even fr the mdule(s) nt tested. Checksum values f each mdule and sftware mdule shall be retrieved frm the Cntactless Prduct submitted and checked by the Labratry against values prvided by the Prduct Prvider in the ICS. It is nt allwed t change any Checksum value during the type apprval, as the prduct submitted shall be the final Prduct Nte: All mdules shall be tested with the latest versin f the test plans. The belw example shws the apprval duratin f a Prduct when perfrming a Subsequent Submissin (where Kernel C-a, C-b, etc, refer t EMVC Kernel C-1 t C-7 nly): Figure 12: Example f Subsequent Submissin f a Prduct

51 Type Apprval Prcedures Page 45 / Delta testing n Kernel When a Prduct Prvider, during Subsequent Submissin and Optimized Prcess, wants t take pprtunity in extending the validity date f the submitted Prduct, delta testing n the nn-mdified sftware mdules can be run n tp f the tests ran accrding t the previus sectin. The Labratries must then perfrm the fllwing delta -testing n the tp f the test as described in sectin 6.8.1, if requested by the Prduct Prvider: Fr each unchanged mdule f the prduct (Kernels and/r Entry Pint): Perfrm delta testing with the delta test between test plan used in the Initial Submissin and the latest versin f each test plans, This cncerns [TA C-n], [TA P], [TA A&B] test plan, The belw example shws the apprval duratin f a Prduct when perfrming a Subsequent Submissin with delta testing (where Kernel C-a, C-b, etc, refer t EMVC Kernel C-1 t C-7 nly): Figure 13: Example f Subsequent Submissin f a Prduct with delta testing

52 Type Apprval Prcedures Page 46 / Errata test lists Fr each [TA C-n] and [Bk A & B] test plan, an errata list is maintained by EMVC between the versins f test plans. This list summarizes the mandatry tests t run in the latest test plan versin whatever is the Kernel(s) sftware versin laded in the Prduct. The belw figure shws an example f Optimized Prcess with Initial Submissin and Subsequent Submissin with additinal Kernel fr the same prduct:

53 Type Apprval Prcedures Page 47 / 78 Figure 14: Example f Tests fr Subsequent Submissin f a Prduct ICS Submissin rules Fr all prcesses the fllwing ICS submissin rules applies: ICS Submissin The initial ICS submissin t the EMVC is free f charge. The ICS submitted must be the ICS in pdf frmat, capable f imprting/exprting XML frmat and shall be digitally signed by the Prduct Prvider and the Labratry at the time f submissin t EMVC. The labratry supplies the signed cpy f the vendr-supplied ICS t EMVC fr review prir t the start f the type apprval testing prcess. EMVC will review and apprve the ICS by returning the ICS in pdf digitally signed and with the fficial ICS number. In case the ICS is incrrectly filled, decline fee applies t Labratry ICS replacement One free ICS replacement (per ICS type) is allwed during the ICS life cycle. ICS replacement fee will be charged (t the Prduct Prvider) fr any subsequent ICS replacement request. Same submissin prcess applies as fr initial ICS submissin (Labratry submits the changed ICS). This applies t any change in the ICS after the fficial apprval f the ICS by EMVC. After the start f the test sessin f the Prduct, ICS replacements (fllwing the rules f the previus bullet) are nly allwed fr administrative infrmatin update (such as name f prduct) but nt are nt allwed fr technical infrmatin update. Labratry shall ensure that any ICS change requested is nt made t hide a bug in the prduct (such as deactivatin a functin because this functin is nt wrking prperly). ICS replacement is n mre allwed after Test Reprt submissin t EMVC Nte: ICS decline prcess remains and any errr reprted by EMVC will be charged t the

54 Type Apprval Prcedures Page 48 / 78 Labratry (as Labratry is respnsible f reviewing the ICS prvided by the Prduct Prvider). ICS decline prcess applies t the initial ICS submissin and als t any ther ICS replacement (charged r nt charged t the Prduct Prvider). 4.5 Type Apprval Renewal Prcess Basic Plicy Renewal At the end f the validity perid f the Prduct, EMVC evaluates whether the Prduct demnstrates sufficient cnfrmance t the current EMV Cntactless Specificatins. If the evaluatin result is psitive then EMVC gives an extensin t the Prduct Letter f Apprval. The fllwing rules shall apply t Renewal Request: The Prduct n ging LA is still valid at the time f renewal. The Level 1 LAs must be valid at the time f renewal. The cntact L1, L2 LAs are still valid at the time f renewal (if cntact is present in the Prduct). All EMV Cntactless Specificatins are still valid (Bk A, B and C-n). All EMV Cntact Specificatins are still valid (Bk N1 N2 N3 N4) (if cntact is present in the Prduct). Fr Cntactless Prduct with Derivative Prducts, the fllwing rules als apply: In case sme IFM(s) LA are n mre valid, these cncerned IFM(s) will be remved frm the renewed Cntactless Prduct LA. In case sme PCD(s) LA are n mre valid (if cntact is present in the Prduct), these cncerned PCD(s) will be remved frm the renewed Cntactless Prduct LA. Six mnths befre the renewal date f their Prduct, EMVC will send a ntificatin letter t the Prduct Prvider. After the receptin f this letter and prir t the renewal date, Prduct Prvider may request their renewal by submitting the riginally apprved prduct t EMVC fr renewal testing Nte: Prduct Prviders are nt allwed t apply fr renewal testing befre receiving the ntificatin letter Renewal Test Plan 6 mnths befre the renewal date: The bjective f the renewal testing is t ensure these Prducts pass the mst current EMVC testing. By passing the renewal test, the Prduct will receive an extensin t the Letter f Apprval. If the prducts fail t pass the renewal testing, they will be remved frm the Prduct list and their Letter f Apprval will be cnsidered revked. If the existing samples are n lnger functinal at the Labratry, the Prduct Prvider may submit the riginal sample t a Labratry fr renewal testing.

55 Type Apprval Prcedures Page 49 / 78 The set f the renewal tests will be generated based n the newly added r mdified test cases since the lder test plans that kernels were tested against and the mst current test plans at the time f testing plus regressin testing. The mst current test plan reference is the versin available at the time f the Type Apprval test sessin. Nte: if the existing samples are n lnger functinal at the Labratry and the devices are prvided by the Prduct Prvider, in case f Standard Prcess, a full test sessin is required Labratries fr renewal testing The Prduct Prvider may decide t have a different Labratry t perfrm renewal testing. The Prduct Prvider must make the necessary arrangements t have the riginally apprved Prduct transprted between Labratries. The Prduct Prvider is respnsible fr incurring the csts assciated with this transfer Samples Submissin Renewal testing must be perfrmed n Prducts already physically present at a Labratry. If the Prduct is n lnger present r is therwise inperable, EMVC may accept a replacement Prduct frm the Prduct Prvider fr testing prvided they have signed a disclaimer stating that the replacement Prduct is identical in all respects t the Prduct riginally supplied t a Labratry fr testing (withut mdificatin, same checksum(s),..). Fr this reasn, it is essential that Prduct Prviders retain an exact and unaltered cpy f the Prduct riginally sent t the Labratry during the initial testing phase ICS Submissin If the prduct des nt supprt mandatry features described in the latest versin f the ICS, the Prduct is nt eligible fr renewal. ICS submitted fr renewal testing must be based n the latest versin available at the time f testing.

56 Test Versin and Specificatin Change Page 50 / 78 5 Test Versin and Specificatin Change The fllwing sectins identify the prcess managing type apprval test changes when the specificatin r test cases change. 5.1 Test Changes withut Specificatin Update and Applicatin nte EMVC reserves the right t change type apprval tests at any time in rder t increase the accuracy and integrity f the tests versus the EMV Specificatin, r fr any ther reasns. Figure 15: Example f the timing fr test changes TTA Tests Versin n Applicable Release f TTA Tests Versin n+1 Develpment and Installatin f New Tests Tday N TTA Tests Versin n Beynd this Date TTA Tests Versin n+1 Applicable Start Running New Tests TTA=Terminal ( Type Apprval) Future EMVC will infrm all participants f the new tests and fix the date(s) fr activatin f the new tests and deactivatin f the ld. EMVC may determine a time perid during which either the ld r new test versin may be used in the type apprval prcess (see figure 15). Hwever, EMVC shall nt be under any bligatin t permit a phase-ut f ld tests. 5.2 Test Changes due t Specificatin Update and Applicatin Nte After a change in the EMV Specificatins, EMVC will decide: If and when the type apprval tests must be changed t accmmdate the new specificatins When t intrduce the new type apprval test versin When t stp testing and renewal with the previus type apprval test versin EMVC will infrm all participants f the new tests and the date(s) f the activatin f the new test versin and deactivatin f the ld test versin.

57 Test Versin and Specificatin Change Page 51 / 78 Beynd this date nly terminals cmpliant t the Reference Specificatin Vn+1 will be supprted by EMVC. Reference Specificatin Vn Terminals cmpliant t ld versin f the Ref. Spec. are supprted by EMVC New versin f Reference Specificatin released Ref.Spec. Vn+1 Tday TTA tests Vn Applicable Future N Type Apprval and cmpliance tests t the Ref. Spec Vn beynd this date New versin f TTA tests released Develpment, installatin f new tests New TTA tests applicable Start running Type Apprval and cmpliance tests t the new Reference Specificatin Figure 16: Time line fr test changes, fllwing changes in EMV Specificatin 5.3 Testing Applicability All Prducts will be tested t the current versin f the EMV test cases. Test case applicability is defined by the date determined by EMVC. At which time all new Prducts and Subsequent Submissins submitted n r after this date will be tested t current test plan. Previus versins f the test plan may nt be used and EMVC will reject any testing perfrmed t an ld versin f a test plan after the applicable date.

58 Prduct Changes Page 52 / 78 6 Prduct Changes EMVC recgnizes that frm time t time minr changes may ccur withut affecting Prduct cmpliance t the EMV Specificatin. Hwever, EMVC cnsiders a majr mdificatin t be a change t the Prduct that affects the cmpliance f the Prduct t the requirements f the EMV Specificatin. A Prduct that underges a majr mdificatin shall be cnsidered as a changed Prduct and therefre type apprval is required accrding t the present dcument. A majr change t a Prduct may generate a different behavir f the Prduct with respect t the EMV Specificatin and the Prduct Prvider s ICS. In such cases, the mdified Prduct shall be cnsidered as a new Prduct (nn Mdular Implementatin) r as a changed Prduct (Mdular Implementatin) and new testing and evaluatin is required t extend type apprval t this Prduct. The riginal unchanged Prduct remains type apprved. A minr change in a Prduct des nt generate a different behavir with respect t the specificatins and ICS. In such cases, the Prduct shall nt require new type apprval. It is the respnsibility f the Prduct Prvider t maintain all evidentiary dcumentatin describing why the mdificatin made was minr in nature and culd nt negatively impact the functinality f the Prduct. Any change t a Prduct, the Prduct Prvider shall cntact EMVC t describe the nature f the change befre prcessing any Change Request. TA Bulletin #11 fifth editin, Minr/Majr Changes, will be updated at a later date t cntactless.

59 Change in Cntact Page 53 / 78 7 Change in Cntact The Prduct Prvider shall infrm the EMVC CATA Secretariat if the cmpany name, address r cntact infrmatin changes, as stated in Prduct Prvider registratin. Changes impacting cmpany names may require a new cntract with EMVC. Generally, apprval ntificatin letters are nt reissued when name changes are the result f crprate mergers, sales r ther events cvered by the Assignment and Successrs and Assigns sectins in the cntract between Prduct Prvider and EMVC. Mdificatins t cmpany addresses and cntact infrmatin will be applied t the EMVC web site and subsequent cmmunicatin (i.e. apprval ntificatin) with the Prduct Prvider. Sme rganizatins specify different cntact infrmatin fr varius prducts. Cntact infrmatin changes will be applied t all listed Prduct unless specially stated n the request. If as a result f a cmpany name change, address change r cntact change, EMVC needs t re-issue an existing LA n explicit request frm the Prduct Prvider, EMVC will request an administrative fee per LA re-issuance. Please nte that LA s are nly issued electrnically."

60 Appendix A: Templates and Frms Page 54 / 78 8 Appendix A: Templates and Frms Prduct Prvider can find all vendr frms he needs t cmplete n the EMVC website ( under Terminal Type Apprval, sectin Type Apprval Vendr Frms. Registratin Frm. Vendr Cntract. Implementatin Cnfrmance Statement. Request fr Apprval. Initial Submissin, Subsequent Submissin. Request fr Renewal.

61 Appendix B: Checksum Implementatin Rules Page 55 / 78 9 Appendix B: Checksum Implementatin Rules The Prduct Prvider shall include in the Prduct submitted sftware a checksum cmputatin fllwing the belw rules: Each Kernel Mdule shall have a unique Checksum. The Checksum cmputatin f each Kernel Mdule shall include all requirements f the Kernel Mdule. The Checksum cmputatin shall include the fllwing data element by kernel: Fr Kernel C- 1: Nne Fr Kernel C- 2: Nne Fr Kernel C- 3: Terminal Transactin Qualifier (TTQ) Fr Kernel C- 4: Nne When the Kernel Mdule is based n several Sftware Mdules (such as using external rutines, libraries, etc), each Sftware Mdule shall have a unique Checksum. In this case the Kernel Mdule Checksum shall be the Checksum cmputatin ver all Sftware Mdule checksum values. Any change in a Kernel Mdule r a Sftware Mdule shall generate a new unique Checksum value f the changed Kernel Mdule r Sftware Mdule. Prduct Prvider shall use an algrithm that generates a unique value each time the mdule is changed. The Prduct shall cntain a sftware mechanism t easily retrieve all checksum values f all Sftware Mdules (libraries, Sftware Mdules, Kernels, Entry Pints, ) when these Sftware Mdules are laded in the Prduct. When used, this sftware mechanism shall dynamically cmpute the Kernel and Entry Pint Checksums (nt necessary fr the Sftware Mdules r libraries). These rules apply t Prduct with mdular Architecture r nt. Fr a Cntactless Prduct having a Mdular Architecture, the fllwing Checksum shall be identified independently. A Checksum fr the Bk A & B mdule, A Checksum fr each EMVC Kernel C-n mdules, A Checksum fr each test kernels present in the Prduct. Fr a Cntactless Prduct having a nn Mdular Architecture, a unique Checksum shall be identified. Nte: If a Prduct Prvider submit a first Prduct, and he as nt yet a Mdular Label, Checksums will be required as fr a Cntactless Prduct having an Mdular Architecture (multiple Checksum required). In case that the Mdular Label failed (r is nt requested by

62 Appendix B: Checksum Implementatin Rules Page 56 / 78 the Prduct Prvider), the submitted Prduct will be cnsidered as a Cntactless Prduct having a nn Mdular Architecture, but in that case the referenced checksums in the LA will the multiple checksum prvided and nt the single checksum expected fr a Cntactless Prduct having a nn Mdular Architecture. The belw figure prvides an example f Checksum cverage In this example, the Full Kernel C-n functinalities are split ver a sftware Kernel C-n Mdule (blue bx) and 3 external libraries/mdules (Yellw bxes). Each sftware mdule (Kernel C-n, External Library 1, External Library 2 and External Library n) shall have its wn unique Checksum. The Full Mdule Checksum must be cmputed ver all sftware mdule libraries. Same fr the Kernel C-m. The yellw external libraries/mdules are included in tw different checksums. The value f Kernel C-n checksum and the value f Kernel C-m checksum shall be different. Nte 1: All Checksum cmputatin changes are cnsidered as a majr change f the Cntactless Prduct and require new apprval. Nte 2: Cntactless Prducts submitted fr renewal, where initial submissins were

63 Appendix B: Checksum Implementatin Rules Page 57 / 78 accepted withut the present Checksum rules, are allwed fr renewal submissin withut the present Checksum rules. Nte 3: Cntactless Prducts subsequent submissins, where Initial Prduct was accepted withut the present Checksum rules, are allwed fr subsequent submissin withut the present Checksum rules.

64 Appendix C: Type Apprval f Derivative Prduct Page 58 / Appendix C: Type Apprval f Derivative Prduct The purpse f this appendix is t describe the EMVC administrative prcedures when the Prduct Prvider wants t submit a Derivative Cntactless Prduct fr apprval Definitin f a Derivative Cntactless Prduct A Derivative Cntactless Prduct is a derivatin f a Cntactless Prduct fllwing the standard Cntactless Prduct definitin: FIT ICR Cmb A Derivative Cntactless Prduct, is based n an apprved Cntactless Prduct and ne f the fllwing changes has been made: Change in (r f) PCD Change in (r f) IFM (if present) Adding a new Cnfiguratin in the Cntact L2 MCK prcess (if present) Any ther change (such as sftware change) f an apprved Cntactless Prduct is nt cnsidered as a derivatin and therefre cannt fllw the present Type Apprval Prcess fr Derivative Cntactless Prduct Type Apprval Prcedures The present sectin describes the Type Apprval Prcedures fr Derivative Cntactless Prduct Derivative Cntactless Prduct Type Apprval apprach The belw figure shws an example f several Derivative Cntactless Prducts derived frm the same initial Cntactless Prduct. In the example, the derivatives are: Change f the PCD fr Derivative Prduct 1 and 2. Adding new MCK cnfiguratins in the L2 MCK Kernel (the initial prduct cntained a cntact part with IFM and L2 MCK kernel) fr Derivative Prduct 3, 4 and 5. Change r new cntact IFM (initial prduct cntained a cntact part with IFM and L2 MCK kernel) fr Derivative Prduct 6, 7 and 8.

65 Appendix C: Type Apprval f Derivative Prduct Page 59 / 78 This figure shws that frm the Initial Prduct, the Prduct Prvider will submit 8 Derivative Cntactless Prducts and fr each submissin, the figure shws what testing needs t be perfrmed Derivative Cntactless Prduct Prcedures The belw figure shws the diagram f a Type Apprval Prcesses fr Derivative Cntactless Prduct:

66 Appendix C: Type Apprval f Derivative Prduct Page 60 / 78

67 Appendix C: Type Apprval f Derivative Prduct Page 61 / PCD Change Derivative Cntactless Prduct When the change in the Cntactless Prduct relates t the PCD, the Prduct Prvider shall: Fllw the standard Type Apprval prcess fr PCD (EMVC Type Apprval Cntactless Terminal Level 1 Administrative Prcess, latest versin), and btain the L1 cntact LA f the new/changed PCD, Perfrm the Derivative Cntactless Prduct Type Apprval (see sectin belw) Submit the Derivative Cntactless Prduct Request fr Apprval (see sectin belw) Nte1: The PCD L1 Cntactless Type Apprval Prcess maybe perfrmed in parallel with the Derivative Cntactless Prduct Type Apprval Prcess, as lng as the PCD LA has been granted befre submitting the Derivative Cntactless Prduct Request fr Apprval IFM Change Derivative Cntactless Prduct When the change in the Cntactless Prduct relates t an apprved IFM Cntact cmpnent, the Prduct Prvider shall: Perfrm the standard Type Apprval prcess fr IFM (Terminal Level 1 Administrative Prcess, latest versin), and btain the L1 cntact LA f the new/changed IFM, Apply the Derivative Cntactless Prduct Request fr Apprval (see sectin belw) Nte1: This prcess nly applies if IFM initially referenced in the apprved Cntactless Prduct Nte2: Fr IFM change, n additinal testing is required fr the verall Derivative

68 Appendix C: Type Apprval f Derivative Prduct Page 62 / 78 Cntactless Prduct Apprval New MCK L2 Cntact cnfiguratin Derivative Cntactless Prduct When the change in the Cntactless Prduct relates t an additinal L2 Cntact Kernel MCK cnfiguratin ( L2 Cntact kernel referenced in the Cntactless Prduct), the Prduct Prvider shall: Perfrm the standard Type Apprval prcess fr additinal L2 Cntact Kernel MCK cnfiguratin (Terminal Level 2 Administrative Prcess, latest versin), and btain the L2 cntact LA fr the new MCK cnfiguratin, Submit the Derivative Cntactless Prduct Request fr Apprval (see sectin belw) Nte1: This prcess nly applies if the L2 Cntact Kernel is initially referenced in the apprved Cntactless Prduct. Nte2: Fr additinal MCK cnfiguratin, n additinal testing is required fr the verall Derivative Cntactless Prduct Apprval Derivative Cntactless Prduct Type Apprval Prduct Prvider and Labratry Operatins The Prduct Prvider and the Labratry perfrm the fllwing peratins as per type apprval prcedure: The Prduct Prvider is free t select any EMVC accredited Labratries fr the purpse f achieving EMVC Cntactless type apprval. Once the labratries are selected, the Prduct Prvider and Labratries execute a cntract defining the individual rights and bligatins f the cntracting parties. The prvisins f Prduct Prvider/Labratry cntract are up t the cntracting entities and entirely ut f EMVC s scpe. Any fees payable t the Labratry in respect f the tests t be cnducted are slely at the discretin f the Labratry. The Prduct Prvider sends the apprpriate Implementatin Cnfrmance Statement (ICS) t the chsen Labratry fr each Prduct under test that it submits. The ICS frmat and cntent requirements are determined by EMVC. The Labratry(ies) tests the Prducts in accrdance with EMVC test prcedures belw. The Labratry(ies) sends the final test reprts t the Prduct Prvider being the wner f the test results. The Labratry(ies) must advise EMVC f any failures that have been encuntered during testing. The Labratry(ies) submits an riginal cpy f the test results reprt t the EMVC CATA Secretariat, and ensures that the Prduct Prvider has already submitted relevant cmpleted Request Fr Apprval frm. Testing prcedure fr apprval: The Labratries must perfrm the fllwing testing prcedure: Multi-Kernel Independency testing using [TA M], where independency test set f all C Kernel(s) present in Prduct applies (n mdular testing), with the fllwing

69 Appendix C: Type Apprval f Derivative Prduct Page 63 / 78 prcess: Verify that Independency Tests pass crrectly (transactins accepted) fr all C kernel(s) present. Perfrmance Testing using [TA P], fr each Kernel C-n present Testing must be dne with the final prduct. This means Labratries must verify the checksum f each mdule (Entry Pint, Kernels C-n present in the prduct), even fr the mdule(s) nt tested. These checksums values shall be the same as the ne declared in the ICS and the ne in the initial prduct. It is nt allwed t change any Checksum values during the type apprval, as the prduct submitted shall be the final Prduct. Type Apprval Test Reprt The test reprts must include the fllwing infrmatin: Identificatin f the Labratry. Identificatin f Prduct Prvider. Identificatin f Derivative Prduct. Identificatin f the INITIAL Prduct. Identificatin f the new/changed PCD Prduct Prvider signed Implementatin Cnfrmance Statement identifying Prduct that has been tested. Als fr each tl used the belw infrmatin: Ø Ø Ø Ø EMVC Cntactless Specificatin/test case versin used fr test, Identificatin f all Labratry test equipments and sftware versins used during the tests, Dates tests were perfrmed, The test case executin results in the test reprts fr each test case: EMVC defined test case number and title, Pass, Fail, r Nt Applicable test result, Fr Nt Applicable designated test case results, an explanatin justifying this designatin, Additinal Labratry cmments, if apprpriate, A detailed descriptin f any exceptin test(s) perfrmed r equipment utilized and a descriptin f related test results, A detailed descriptin f the Prduct Prvider s mdificatins that may be required fr the purpse f successfully executing the EMVC test cases Derivative Cntactless Prduct Request fr Apprval Prduct Prvider Request fr Apprval The Prduct Prvider prepares the Request fr Apprval frm and submits it t the EMVC CATA Secretariat.

70 Appendix C: Type Apprval f Derivative Prduct Page 64 / 78 EMVC can then issues the invice fr the Prduct Prvider. Prduct Prvider submits payment t EMVC based n the received invice. The request fr review will cmprise: Letter requesting apprval (RFA frm) fr Derivative Prduct. The cmplete and unchanged test reprts as received frm the Labratry(ies), fr PCD change nly. EMVC invice settled. Any additinal supprting dcumentatin the Prduct Prvider believes is apprpriate. EMVC Apprval Upn receiving the request, EMVC will: Review the submitted test reprts and determine if type apprval shuld be granted fr the Prduct, fr PCD changes nly. Ntify the Prduct Prvider f type apprval r denial fr the Prduct. Update the Letter f Apprval f the initial Cntactless Prduct, if apprpriate. Prvide ntificatin f EMV Prduct type apprval. The Cntactless Prduct LA f the initial Prduct will be updated t identifies all apprved Derivatins f this Cntactless Prduct, and this n the same LA (which will be updated with the derivative infrmatin s f each derivatin apprved). LA, depending n the derivatin, will be updated with: The apprved Level 1 PCD(s) added fr this prduct. The apprved Level 1 Cntact IFM(s) added fr this prduct (if present). The apprved Level 2 Cntact Kernel(s) added fr this prduct (if present). The rest f the LA infrmatin remains strictly identical t initial Prduct LA (fr example Expiratin Date remains the date f the initial Prduct submitted) Subsequent Submissin and Derivative Cntactless Prduct This sectin describes a case as fllws: A Cntactless Prduct was Type Apprved. Derivative Cntactless Prduct(s) was Type Apprved based n the initial Cntactless Prduct and listed n the same LA. The Prduct Prvider wants t submit a Subsequent Submissin f the Initial Cntactless Prduct (due t a Kernel r an Entry Pint change) and its Derivative Cntactless Prducts listed n the same LA.

71 Appendix C: Type Apprval f Derivative Prduct Page 65 / 78 Fr this case the fllwing rules applies: 1. The Subsequent Submissin f the Cntactless Prduct applies as described in sectin f the present dcument (Subsequent Submissin). 2. Fr all Derivative Cntactless Prduct listed n the LA, with derivatin related t an IFM change r a MCK cnfiguratin, the Derivative Cntactless Prduct Prcess applies as described in sectin , but they are submitted in a single Subsequent Submissin request. Nte: If the IFM r MCK cnfiguratin were already type apprved, n testing is required, nly the LA issuance. 3. Fr each Derivatin related t a PCD change, the Derivative Cntactless Prduct Prcess applies as described in sectin with the fllwing change in the sectin : a. Case f a PCD which has been Type Apprved in ne f previus Derivative Cntactless Prduct: i. If the Subsequent Submissin cncerns a change/additin f a Kernel C-n (C-1 t C-7): The testing f sectin is limited t the Labratry able t run the Kernel C-n testing (nly ne labratry is needed). The Labratry selected has t run the Multi Kernel Independency and Perfrmance tests but limited t: ii. Ø Ø Perfrmance Testing using [TA P], limited t the cncerned Kernel C-n (N perfrmance testing f the ther Kernel present) Multi-Kernel Independency testing using [TA M] fr all Kernel(s) present, (n mdular testing). Where the test cases f the cncerned Kernel C-n shall have a psitive result, and the transactins f the test cases f the ther kernels present (C-1 t C-7 and C-REG X ) shall be apprved (n need t verify the pass criteria f these test cases) If the Subsequent Submissin cncerns a change in Bk A & Bk B (Entry Pint) mdule: n testing required fr sectin iii. If the Subsequent Submissin cncerns a change/additin f a Kernel C-REG X : The testing f sectin is limited t the Labratry able t run the Kernel C-REG X testing (nly ne labratry is needed). Multi-Kernel Independency testing using [TA M] fr all Kernel(s) present, (n mdular testing). The test cases f the cncerned Kernel C-REG X shall have a psitive result, and the transactins f the test cases f the ther kernels present (C-1 t C-7) shall be apprved (n need t verify the pass criteria f these test cases). iv. If the Subsequent Submissin cncerns a change/additin f a the Cntact Applicatin Kernel cmpnent (if present in the Prduct): n testing required fr sectin b. Case f a PCD which has nt been Type Apprved in ne f previus Derivative Cntactless Prduct: standard testing f sectin applies. The Figure belw shws an example f this prcess when the Subsequent Submissin cncern a Kernel C-n change/additin: Fig. X: Kernel C-n chane/additin case

72 Appendix C: Type Apprval f Derivative Prduct Page 66 / 78 Nte: Prduct Prvider as t submit a single Subsequent Submissin whatever is the number f derivatin present in the Cntactless Prduct, and therefre t pay nly nce the subsequent submissin fees.

73 Appendix D: Mdular Architecture fr Terminal with separate Cntact/Cntactless Architecture Page 67 / Appendix D: Mdular Architecture fr Terminal with separate Cntact/Cntactless Architecture The present annex describes a specific case f Terminal Architecture cnsidered as Mdular Architecture. This case cvers single bx Terminal with a Cntact Prduct and a Cntactless Prduct present nbard. These Cntact and Cntactless Prducts are ttally separated. This separatin applies t the Sftware and Hardware architecture. In this architecture, there is n cmmn kernel, n libraries shared, n cmmn drivers, between Cntact and Cntactless. In this specific case, the Cntact part f the Terminal culd be cnsidered as independent frm the Cntactless part, in which case the Prduct has tw independent sftware mdules in the Terminal. EMVC cnsiders this specific case as a Mdular Architecture hence, this Prduct culd apply fr Mdular Label where tw sftware mdules are present: the Cntact Mdule and the Cntactless Mdule. As fr any ther Mdular Architecture, after granting the Mdular Label, all rules applying t Mdular Architecture are valid, such as: - Sftware mdule change r update, - Derivative Prduct LA, - S the tw prducts f the Terminal can change independently frm each ther. Testing requirement: Fr this specific Mdular Architecture, Mdular testing shall nt be perfrmed. All thers testing requirements f this dcument apply as per the prcesses. Examples f such architecture culd be: - a S-ICR (figure 2 f the present dcument) where the cntact part is in the Terminal (POS System) and n relatinship between Reader and Terminal Sftware (s tw separated sftware architecture).

74 Appendix D: Mdular Architecture fr Terminal with separate Cntact/Cntactless Architecture Page 68 / 78 Fig. X: Example f s-icr - An ATM where bth Cntact and Cntactless Hardware and Sftware are strictly separated.