Contactless Product Modular Requirements

EMV® Terminal Type Approval Contactless Product __________________________________________________ Modular Requirements Version 1.7.r - draft September, 2025 © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 3 / 6 Legal Notice This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or noninfringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON- INFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 4 / 6 technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 5 / 6 Revision Log – Version 1.7.r The following changes have been made to the document since the publication of Version 1.7. Some of the numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. The numbering of existing requirements did not change, unless explicitly stated otherwise. Section Reason for change Editorial Updates © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 6 / 6 1 SCOPE......................................................................................................................................................8 2 NORMATIVE REFERENCES..............................................................................................................9 2.1 REFERENCE DOCUMENTS....................................................................................................................9 3 GLOSSARY OF TERMS .....................................................................................................................10 3.1 ABBREVIATIONS AND NOTATIONS ....................................................................................................10 3.2 DEFINITIONS .....................................................................................................................................10 4 MODULAR ARCHITECTURE REQUIREMENTS ........................................................................13 4.1 PRODUCT DEFINITION.......................................................................................................................13 4.1.1 Fully Integrated Terminal (FIT):..............................................................................................14 4.1.2 Intelligent Card Reader (ICR), .................................................................................................15 4.1.3 Combination of Terminal and Transparent Card Reader:.......................................................18 4.2 MODULAR ARCHITECTURE ...............................................................................................................19 4.2.1 Modular Architecture with External Dependencies .................................................................20 4.2.2 Testing of External Dependencies ............................................................................................23 4.3 QUALITY CRITERIA TO FOLLOW FOR THE MODULAR ARCHITECTURE...............................................24 4.3.1 Tightness (Clear separation between modules)........................................................................24 4.3.2 Plug-In Ability (Loading/Deleting module): ............................................................................24 4.3.3 Data Integrity ...........................................................................................................................24 4.3.4 Maintenance .............................................................................................................................24 5 ELIGIBILITY CRITERIAS ................................................................................................................25 5.1 RELATIONSHIP BETWEEN QUALITY CRITERIA AND ELIGIBILITY CRITERIA ......................................25 5.2 WELL DEFINED INTERFACES.............................................................................................................25 5.3 PROTECTION .....................................................................................................................................26 5.4 WEAK COUPLING..............................................................................................................................27 5.5 VERSION MANAGEMENT...................................................................................................................28 5.6 TESTABILITY.....................................................................................................................................28 5.7 MEMORY MANAGEMENT ..................................................................................................................28 6 ELIGIBILITY CHECKLIST...............................................................................................................29 7 APPENDIX A.........................................................................................................................................32 8 APPENDIX B: CHECKSUM RULES.................................................................................................34 9 APPENDIX C.........................................................................................................................................36 10 APPENDIX D: MODULAR ARCHITECTURE FOR TERMINAL WITH SEPARATE CONTACT/CONTACTLESS ARCHITECTURE ...................................................................................38 11 APPENDIX E: MODULAR AUDITORS ELIGIBILITY CHECKLIST........................................40 11.1 PROTECTION (PROT) CRITERIA......................................................................................................40 © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 7 / 6 11.2 WELL DEFINED INTERFACES (WELLDEF) ....................................................................................41 11.3 WEAK COUPLING (WC)..................................................................................................................41 11.4 VERSION MANAGEMENT (VM).......................................................................................................42 11.5 TESTABILITY (TEST)......................................................................................................................43 11.6 MEMORY MANAGEMENT (MM) .....................................................................................................43 11.7 SOFTWARE MANAGEMENT (SWM)..................................................................................................44 © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements Page 8 / 6 1 SCOPE EMVCo offers two Processes to Type Approve Contactless Products: • The ”Optimized Process” for Products which adhere to the design principles outlined in this document referred to as the Modular Architecture. • The ”Standard Process” for Products that do not apply these EMVCo design principles. The objective of this document is to describe the requirements of the Modular Architecture. A Product Provider must follow these design principles and acquire a Modular Label if he wishes to submit his product(s) for EMV Type Approval employing the ”Optimized Process”. The Purpose of ”Optimized Process” is to streamline the EMV Type Approval by limiting the tests EMVCo requires to the modified software module(s) of the Product. The process of acquiring the Modular Label affords EMVCo a method of recognizing that a Product is built according to the vendors Modular Architecture. Designing the Product according to the Modular Architecture allows EMVCo to minimize the testing of the other unmodified module(s) to those that assure the principle of modularity exists within the Product and the independency of the various modules within the Product. The present document in not intended to impose a particular software architecture. Product Providers can propose and implement any software architecture, as long they follow the design principles described in the Modular Architecture section (4.2). This implicitly requires that modules developed by the Product Provider are separately testable – i.e. controllable and externally observable - which supposes that every module is designed and tested following “state-of-the-art” methodologies, which can indeed differentiate one product provider to another. The target audience of this document includes: • Product Providers • Auditors acting on behalf of EMVCo for Compliance audit of Product Providers Modular Architecture. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Terminal Type Approval Contactless Product Modular Requirements 2 NORMATIVE REFERENCES 2.1 REFERENCE DOCUMENTS Page 9 / 36 [N1] [N2] [N3] [N4] [Book A] [Book B] [Book C-n] [ICS] [TA A&B] [TA M] [TA Admin] EMV Integrated Circuit Card Specification for Payment Systems – Book 1 – Application Independent ICC to Terminal Interface Requirements EMV Integrated Circuit Card Application Specification for Payment Systems – Book 2 – Security and Key Management EMV Integrated Circuit Card Terminal Specification for Payment Systems – Book 3 – Application Specification EMV Integrated Circuit Card Terminal Specification for Payment Systems – Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements EMV Contactless Specifications for Payment Systems – Book A – Architecture and General Requirements EMV Contactless Specifications for Payment Systems – Book B – Entry Point Specification EMV Contactless Specifications for Payment Systems – Book C-n – kernel Specification, where n refers to Kernel 1 to 4 EMVCo Type Approval Contactless Product Implementation Conformance Statement EMVCo Type Approval Contactless Product- Book A & B Test Plan EMVCo Type Approval Contactless Product Modular Test Plan EMVCo Type Approval Contactless Product – Administrative Process Version 4.3 – November 2011 Version 4.3 – November 2011 Version 4.3 – November 2011 Version 4.3 – November 2011 Latest version available Latest version available Latest version available Latest version available Latest version available Latest version available Latest version available © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements 3 GLOSSARY OF TERMS 3.1 ABBREVIATIONS AND NOTATIONS FIT Fully Integrated Terminal ICC Integrated Circuit Card ICR Integrated Card Reader ICS Implementation conformance statement IEC International Electrotechnical Commission IFM Interface Module ISO International Organization for Standardization Lab Laboratory LoA Letter of Approval M-ICR Multi Component ICR ML Modular Label PCD Proximity Coupling Devices PICC Proximity Integrated Circuit Card RFA Request for Approval S-ICR Single Component ICR PRP Product Provider TTA Terminal type approval Page 10 / 36 3.2 DEFINITIONS Check Sum - A Product Provider-generated value (4-20 bytes) for each module. This checksum must be a unique value for each module. The method or algorithm used for © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 11 / 36 generating the checksum is left to the discretion of the Product Provider. For example, a Product Provider may choose to implement SHA-1 or CRC. These value shall be retrievable for each Kernels Modules, Software Modules, External Libraries or Entry Point Modules when loaded in the Product and this for comparative purposes. Refer to annex B for more detail on Checksum defined rules. Compliance - meeting all the requirements and also any implemented optional requirements Combination List – List of combinations supported by the Product. A combination is a couple AID-Kernel, as defined in Book B. Eligibility Criteria – an Eligibility Criteria defines requirements that Modular Architecture must comply with, to be eligible for the ‘Optimized Process’. Eligibility Check List – List of Eligibility Criteria that the auditor verifies during the audit of the Modular Architecture. Entry Point - A POS System software module managing application (AID) and kernel selection according to [Book B]. External Dependency - An independent software module or library used by one or several modules. Function - A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. Implementation Conformance Statement (ICS) - A form completed by the product provider. This written statement lists all optional functions as specified in the reference specifications. Interface - Technical requirements for exchanging data and functions between two software modules. Kernel - Is a software module or collection of modules compliant to one of the [Book C-n] Specifications. Laboratory - An EMVCo recognised facility that performs type approval testing. Letter of approval - Written statement that documents the decision of EMVCo that a specified product type has demonstrated sufficient compliance to the EMV Contactless Specifications on the date of testing. Lower Tester – Card simulator of the test tool that communicates with the product under test. Modular Architecture – A software architecture that follows the requirements defined in this document. A Product developed based on an Architecture that has received a Modular Label can be submitted for type approval under the ‘Optimized Process’. Modular Label - Written statement that documents the decision of EMVCo that the Product Providers specified software architecture has demonstrated sufficient compliance to the EMV modular requirements on the date of the audit. Optimized Process – Type Approval process for Product(s) developed based on the Product Providers Architecture that has received the Modular Label and continues to adhere to the Modular Architecture as confirmed by specific tests defined by EMVCo. Persistent Data – Data that are persistent in the terminal and not transaction dependent such as CAPK, TACs, etc. POS System - According to definition Book A in section 4.3. It represents the device that communicates with contactless cards, processes contactless transactions, and may support © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 12 / 36 other payment functionalities such as magnetic stripe or contact chip transactions. Procedure - Specified way to perform a set of tasks. Product - According to the definition in section 4.1 which defines the product to be type approved during the Type Approval process. Quality Criteria – A Quality Criteria defines requirements that Modular Architecture shall support. Reference specification (EMV Contactless Specifications) - A set of documents defining the requirements the Product shall comply with. The reference specification consists of the current EMV Contactless Specifications (Book A, B, C-n, D) for Payment Systems and any additional documentation required when performing type approval. Request for approval - A form that accompanies a product submitted to EMVCo for type approval and marks the launch of his invoice Sandbox: Is a security mechanism for separating running programs. It is often used to execute untested code, or untrusted programs from unverified third-parties, suppliers and untrusted users Software Module - A self-contained program that carries out a clearly defined task and is intended to operate within a larger program suite. Typically a module represents a Kernel Cn or Entry Point. Standard Process - Type Approval process for non-compliant Product(s) with the Modular Architecture according to [TA Archi], Test - Any activity that aims at verifying the compliance of a selected product or process to a given requirement under a given set of conditions. Test case - A description of the actions required to achieve a specific test objective. Type approval - The acknowledgment by EMVCo that the specified Product has demonstrated sufficient compliance to the EMV Contactless Specifications. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 13 / 36 4 MODULAR ARCHITECTURE REQUIREMENTS This section describes the Modular Architecture requirements that a Product Provider needs to implement in his software architecture in order to apply for Type Approval employing the ”Optimized Process”. The rationale of this Modular Architecture is that the software architecture associated with the Product shall be defined in structured module manner, with clearly defined Interfaces between each module. 4.1 PRODUCT DEFINITION This section defines the Contactless Product (called the ”Product”) that is tested by the contactless Type Approval process. The Product is based on the POS System as defined in Book A. A POS System is the device that communicates with contactless cards, processes contactless transactions, and may support other payment functionalities such as magnetic stripe or contact chip transactions. The basic functions of the POS System include: • communication with contactless cards • application selection and kernel activation • displaying messages to the cardholder • displaying messages to the merchant • accepting merchant data entry of the transaction amount • cardholder verification (e.g. signature) • provision of online connections • provision of data capture for clearing and settlement • also Entry Point and Kernels C-1 to C-4 shall be located in the POS System The physical architecture of the POS System can be any of the following, according to Book A definition • Fully Integrated Terminal ”FIT”: All elements included in a single device. • Intelligent Card Reader ”ICR”: The reader handles most of the contactless transaction processing, passing the results for completion by the terminal. • Combination of terminal and transparent card reader: The reader provides communication with the card, whilst kernels and other processes are in the terminal. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements 4.1.1 Fully Integrated Terminal (FIT): All elements of POS System included in a single device. Page 14 / 36 Figure 1: Fully Integrated Terminal The FIT includes: • A valid Level 1 Contactless PCD with an EMVCo Letter of Approval according to Book D • Entry Point and POS System Architecture according to Book A and B • EMV contactless Kernels according to Book C-1 to C-4 including (refer to note below): o Kernel transactions flow, o Kernel functions o EMV data management, o Cryptography, o …. • Consumer & merchant interface(s) • If present, the contact and mag stripe part of the FIT: o IFM (L1) o EMV contact Kernel (L2) • Acquiring Network interface In this definition the Fully Integrated Terminal and the POS System are identical and contain the product. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 15 / 36 4.1.2 Intelligent Card Reader (ICR), The reader handles most of the contactless transaction processing, passing the results for completion by the terminal, two implementations are possible: • Single Component ICR (S-ICR), where all EMV components (EMV requirements defined in Book A, B, C and D) are in the reader. The Product submitted for approval will be the reader alone: Figure 2: Single Component ICR (example 1) Figure 3: Single Component ICR (example 2) The ICR includes: • A valid Level 1 Contactless PCD with an EMVCo Letter of Approval according to Book D • Entry Point and POS System Architecture according to Book A and B • EMV contactless Kernels according to Book C-1 to C-4 including (refer to note below): o Kernel transactions flow, © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements o Kernel functions o EMV data management, o Cryptography, o …. • If present, the contact part of the ICR: o IFM (L1) o EMV contact Kernel (L2) Page 16 / 36 In this definition the Intelligent Card Reader and Product are identical and are part of the POS System. Note: if present, the Contact part can reside either in the Terminal or in the ICR. • Multi Component ICR (M-ICR): In this second case, The M-ICR contains most of the EMV components (EMV requirements defined in Book A, B, C and D) are in the reader. The Product submitted for approval will be the reader and the identified terminal. Figure 4: Multiple Component ICR (example 1) © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Figure 5: Multiple Component ICR (example 2) Page 17 / 36 The ICR includes: • A valid Level 1 Contactless PCD with an EMVCo Letter of Approval according to Book D • Part of Entry Point and POS System Architecture according to Book A and B • Part of EMV contactless Kernels according to Book C-1 to C-4 • If present, the contact part of the ICR: o IFM (L1) o EMV contact Kernel (L2) In this definition the Intelligent Card Reader is part of the Product, which is part of the POS System. Note: if present, the contact part can reside either in the Terminal or in the ICR. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 18 / 36 4.1.3 Combination of Terminal and Transparent Card Reader: The reader provides communication with the card, whilst kernels and other processes are in the terminal. Figure 6: Transparent Reader Combination (example 1) Figure 7: Transparent Reader Combination (example 2) According to the above definitions: a contactless Product submitted for approval © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements shall always include the following: Page 19 / 36 - The POS System according to the above definitions with: • A valid Level 1 Contactless PCD with an EMVCo Letter of Approval according to Book D • Entry Point and POS System Architecture according to Book A and B • EMV Kernels according to Book C-1 to C-C4, including (please refer to note below): o Kernel transactions flow, o Kernel functions o EMV data management, o Cryptography, o …. • If present, the contact part of the ICR: o IFM o EMV contact Kernel Note: The Payment Application shall not contain any Entry Point (Book B) or Kernels (Books C-n) functionalities. 4.2 MODULAR ARCHITECTURE The Modular Architecture of a contactless Product to be type approved with Optimized Process shall comply as a minimum to the following module definition architecture: © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 20 / 36 Figure 7 – Overall Modular Architecture Where: • Entry Point, following [Book A & B] requirements, is a software module • Each Kernel C-1 to C-4, following [C-n] requirements, is an independent software module And where all above modules and necessary interfaces shall be clearly defined in the relevant Product Provider document set. Also the modules shall comply with the checksum rules as defined in annex A of the present document. 4.2.1 Modular Architecture with External Dependencies The Modular Architecture of Figure 7 does not preclude more advanced or detailed modules division, such as: • Division of a module in sub-modules. • Usage by modules of external modules. For the Modular Architecture, the modules should be self-contained and only rely on the dependencies defined in the above © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 21 / 36 architecture (figure 7). In reality, this may be impractical and result in needless duplication of functionality. So it is expected that some modules will rely on external dependencies. An External Dependency is another library, or module, that is not statically linked to the module under test. A statically linked library is not considered external since the relevant code is included in the module under test. Figure 8 – Modules with Contactless-specific External Dependency How modules can be divided into sub-modules or with external dependencies is the Product Provider’s responsibility as long as these divisions comply with the rational of section 4. The present section describes some examples of Modular Architecture with External Dependencies. There are two general categories of External Dependencies: 1. Libraries, or modules, that are integral to the contactless solution. For example, within the Entry Point and Kernels, there is a need for a variety of functions related to handling EMV transactions and data. A common design approach is to group these functions into a separate library, as illustrated in Figure 8. Usually in this architecture, the external library is within the contactless software “package”. As such, detailed knowledge of the source code and revisions are known and fully understood by the product provider. 2. Libraries, or modules, that are available within the POS System and not specific to the contactless solution. Figure 9 shows an example. In this case, the Entry Point relies on a platform cryptographic function library which is also used by other applications within the POS system such as EMV contact Kernel. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 22 / 36 Figure 9. Module using POS System provided External Dependency In this architecture, the source code of the external libraries may not be public. Complete information on the design as well as details on revisions may also not be available. In addition, library updates may be distributed separately from the contactless solution. Figure 10 shows another possible implementation of external dependency. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 23 / 36 Figure 10 - Module using POS System provided External Dependency (example 2) 4.2.2 Testing of External Dependencies If a Kernel module or the Entry Point module uses External Dependencies (for examples in figures 8, 9 and 10 above), then the testing of that module will cover all parts of that module: the external dependencies (external modules or libraries) will be tested during the module’s testing (in both processes Standard and Optimized). For example figure 10, if the Kernel C-n has been tested, then all modules included in the ‘Full Kernel C-n’ (red highlighted part of the figure) will be tested: • Kernel C-n (blue module) • External Library/Module 1 (yellow module) • External library/module 2 (yellow module) © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 24 / 36 If an External Dependencies used in both Contactless and Contact (If Contact is present in the Product) part of the Product is modified, then both Contact and Contactless must be retested. 4.3 QUALITY CRITERIA TO FOLLOW FOR THE MODULAR ARCHITECTURE The following quality criteria shall be followed to comply with the Modular Architecture. 4.3.1 Tightness (Clear separation between modules) • Ensure that adding/deleting new modules: will not affect the other already installed modules or libraries. • Prevent unexpected changes in the software or data of any module: the modular architecture implementation shall ensure that any module of the product is protected (shielded) against any inappropriate - voluntary or involuntary – attempt of changes in these modules and EMV related data (transaction logs, Entry Point and Kernels parameters, list of supported combinations ..) that are handled wherever the location of the data. • Ensure that Entry Point activates the selected kernel C-n: Following the Book B specification, when selecting a Kernel C-n, Entry Point hands over control to the kernel of the selected Combination. 4.3.2 Plug-In Ability (Loading/Deleting module): This criterion translates the capability of Modular Architecture of loading and deleting modules (such as Kernel) – one by one or all together - within the Product. The following levels of Plug-In Ability shall be implemented: • Loading: capability to load a complete module (such as a Kernel) • Deleting: capability of erasing from the terminal memory a Kernel, where the memory can be reused (In some terminal implementation, the deleting just erase the link to the module, but the memory cannot be reused. These implementations are acceptable, as long as the erased module cannot be accessed anymore.) • Updating: capability to load and replace an existing Kernel. However this level can be skipped when the product is capable of the combination of the previous 2 (deletethen-load). 4.3.3 Data Integrity This criterion translates the capability of Modular Architecture to securely store the EMV related data such as Combination List, Entry Point data sets, Kernels C-1 to C-4 data sets. This criteria is made to ensure that nobody except the owner is able to change/update it regardless of the location of the data. This also translates the Product’s capability to securely store the transaction logs generated by all kernels, which also guarantees the tightness of the transactions. 4.3.4 Maintenance This criterion translates the capability to maintain all the software modules of the product separately, whichever the type of maintenance: evolution, adaptation, correction, refurbishing. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 25 / 36 5 ELIGIBILITY CRITERIAS Eligibility of the Modular Architecture is determined by audit of documentation provided by the Product Provider such as: • Software architecture design, • Product Provider internal testing plan The documentation must explain how the software implements modularity and meets the above quality criteria, and how the Product Provider verifies this. To ensure the eligibility evaluation documentation contains the proper content, the present section defines a set of Eligibility Criteria. The Eligibility Criteria focuses on measuring and documenting the modularity of the software using the Modular Architecture. These Eligibility Criteria will be the base of the audit. The criteria is further expanded into an Eligibility Checklist. Using this checklist, Product Providers can determine if their solution will comply with the Modular Architecture and if so be able to submit their product utilizing the Type Approval ‘Optimized Process’. This checklist is used by the auditor to determine compliancy of the Modular Architecture. In order to easily and consistently evaluate software solutions for eligibility, Appendix A provides recommendations for the organization of the eligibility evaluation documentation. 5.1 RELATIONSHIP BETWEEN ELIGIBILITY CRITERIA QUALITY CRITERIA AND The relationships between the Eligibility Criteria and the Quality Criteria are shown in below Table: Protection Weak Coupling Well Defined Interface Version Management Testability Memory Management Tightness x x x Plug-In Ability x Data Integrity x Maintenance x Context Consistency x x x x x x x x x 5.2 WELL DEFINED INTERFACES The module must have Well Defined Interfaces, hence the module’s expected behavior is clear and unambiguous. In turn, the test process can be optimized to take advantage of a set of known inputs and outputs. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 26 / 36 To be eligible for the Modular Architecture, a module must implement an interface consistent with the interfaces defined in the corresponding EMV Specifications (Book A, Book B, Book C-n, N1, etc.). If the module defines any additional interfaces that are not defined in the specifications, then these interfaces need to be documented along with their usage. For example, a module might define an interface to support automated independent unit testing. The following information must be available for each module (and associated sub-modules): • Which are the interfaces? • How do the interfaces map to the interfaces defined in the logical architecture? For any interfaces, which are not part of the logical architecture, what is their purpose and how are they used? • How can the interface definitions be confirmed during the audit process? 5.3 PROTECTION To effectively verify any modifications, a Product following Modular Architecture must not only be modular in design but also ensure that the modules are discrete so that changes in one can’t impact another. The protection of both the module’s code and data must be addressed. There are two general approaches to ensuring modules are protected from unauthorized access. In one approach, the architecture prevents a module from straying outside of its “boundaries”. A “sandbox” is an example of this tactic. Alternatively, the architecture can shield a module from intrusion. The use of protected files is an example of this tactic. Solutions following either approach, or even a hybrid approach, can be eligible for the ‘Optimized Process’. The essential question to be answered is how the implementation protects against intentional, or unintentional, access: • For code, is it possible for other software on the platform to change the module’s code? If so, is this detected and how is the condition handled? • Access to data “inside” the module must be protected. Though, obviously, the Product has requirements to ensure the overall data integrity, the Protection criterion focuses on the data “inside” of the module (or of the sub modules needed for this module). To illustrate this point, consider Figure 7. The Payment Application may have responsibilities to provide each module with its specific configuration data. How the Payment Application correctly manages the overall configuration data is outside of the scope of the Protection criterion. The criterion is concerned with how the data in each module in the overall product (Entry Point, Kernels) is protected: o Is it possible for other platform software to change the module’s runtime data? If so, how does the solution ensure that the module’s data during transaction processing remains valid? o Similarly, if the module maintains any persistent data, can this be changed by any software besides the module? © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 27 / 36 Figure 11 – Configuration Data 5.4 WEAK COUPLING Coupling is the degree to which a module relies on other module(s). Within the Modular Architecture (Figure 7), the modules obviously depend upon each other’s functionality. This dependency covers as a minimum the interfaces specified in figure 7. If the proposed architecture includes additional modules and/or interfaces then these interfaces must be documented. Ideally, for the Modular Architecture eligibility, the modules should be self-contained and only rely on the dependencies defined by the architecture. In reality, this may be impractical and result in needless duplication of functionality. So it is expected that some modules will rely on external dependencies. To achieve Weak Coupling, modules should consider limiting the use of external dependencies, and, where applicable, simplify the dependencies. For example, two way dependencies are obviously more complex and interfaces that require complicated, or state based, data exchanges can be difficult to maintain. Related to the Weak Coupling criterion, the following information must be available for each module: • Besides the interfaces defined in Figure 7, does the module interact in any other way with any of the Modules? If so, why? • Besides the dependencies defined in Figure 7, are there any other external dependencies? If so, for each External Dependency, • What is the version and how can this be verified? © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 28 / 36 • What specific functionality (ex. APIs) is used and when is it used? • Is this dependency part of the contactless solution or is it a platform level dependency? • How can the dependencies be confirmed during the audit process? 5.5 VERSION MANAGEMENT During the life of a contactless Product, it is expected that modules will be independently revised. It must be possible to track the module versions. Versions will be tracked at different levels: • Source: which source code, including revision information, is used to build a module? • In the Product, the solution must be able to detect and report the version information for each module, including any external dependencies. • Version must be certified by checksum 5.6 TESTABILITY Though the logical architecture (Figure 7) defines the relationships for the major software modules, it does not require a specific implementation. The range of possible implementations is at least as varied as the range of contactless Product. Not requiring a specific implementation allows product providers to choose the optimal design for their product. Ideally, each module should be able to be independently and fully tested through its defined interfaces. Without imposing significant additional requirements on both the software vendors and test labs, the Type Approval process cannot realistically expect to perform this type of independent module testing. This is due to the potential variation in implementations as well as the different target platform characteristics. To address this problem, modular testability is an Eligibility Criterion. For a given solution, each module should have a: • Test strategy: How can this module be independently tested? Independent testing should focus on the module interfaces. Techniques such as test harnesses and component emulators can be used, but are not required. Depending upon the detailed architecture and target platform, the product provider can define the most efficient and effective test strategy. • Test plan: Specific range of test cases for this module. • EMV test support: Implementations using the Modular Architecture must support the test requirements to perform EMV modular testing according to [TA M]. 5.7 MEMORY MANAGEMENT In the logical architecture (Figure 7) several Kernel modules can be present and will need allocation of memory and resources. As the Product will support several Kernels, and as the POS System hardware supporting this Product may have additional applications, the Product and its POS System will have various configurations. The Modular Architecture must demonstrate the capability to manage, reserve, allocate and protect the necessary memory and resources for the Product (software and data). © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 29 / 36 6 ELIGIBILITY CHECKLIST The questions in the following checklist fall into two general categories: • Solution Description: These questions are related to describing what the solution looks like, or if not implemented yet, how it will look. • Design Confirmation: These questions address how it can be determined the described solution is implemented. At the time of eligibility evaluation, it is not necessary to show that the design is implemented. But it is necessary to explain how it can later be determined that the design is implemented. However at the time of audit, if the design has been implemented the result of that implementation shall be provided (such as implementation document, test results,…). # Criteria 1 Protection 2 Protection 3 Protection Checklist Is code shielded from write access? If applicable, this applies to both the persistent copy (ex. file or burn image) and the run time image. If not protected from write access, is there any detection? And if so, what is the behavior? Does the solution ensure that the run time data for each module is protected from unauthorized access? Unauthorized access is a write access by any software other than the authorized module. If there is no protection, how is data integrity within transaction processing guaranteed? Does the solution ensure that the persistent data for each module is protected from write access (except by the module)? If there is no protection, how is data integrity guaranteed? 4 Weak Coupling 5 Weak Coupling For each module, are the External Dependencies known and documented? Documentation for an External Dependency includes: • Dependency and version • Specific functionality used in the external dependency. • How is the external dependency distributed? i.e. how does it get into the Product? Is it part of the platform OS? Is it part of the Payment Application? For a specific module implementation, is there a method to verify the exact External Dependencies? For example, can the binary file be inspected to see the dependencies? If it is not possible to verify through inspection of binaries, can it be verified through inspection of other build process artifacts (ex. map files) or by review of the build process (ex. makefiles)? Note: the expectation is not that a test lab would necessarily do this verification. The intent is that if someone asked for this verification, the vendor should be able to provide this type of information. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 30 / 36 6 Weak Coupling For a specific module implementation, is it possible to verify the module’s interfaces to the other module’s conform to the logical architecture? (ex. verify that a Kernel only calls the Card Interface module through the defined interface) 7 Well Defined Interface 8 Well Defined Interface For each module, document the interfaces and how these interfaces map to the logical architecture. • All interfaces in the logical architecture shall be defined. • If the module describes additional interfaces, document the purpose For a specific module implementation, is there a method to verify the exact public interfaces that it provides? 9 Version Management For a specific module implementation, is it possible to report the exact source code versions used to build the module? Note that this does not have to be based on inspection of the module binary. It is acceptable to explain how the organization’s software configuration management practices ensure the source code revisions are known. 10 Version Management In the Product, can the versions of each module be reported and verified? Similarly, can the versions of External Dependencies be reported and verified? 11 Version Management Can the Product identify any unexpected module versions? If so, how is this situation handled? Note: there is no requirement that a Product should not run due to an unexpected module version. This purpose of this question is to identify if any checks are in place. 12 Version Management The Modular Architecture shall be uniquely identified on top of the name (with version and/or date) 13 Testability 14 Testability 15 Testabilty For each module, is there a strategy to independently test the module? And is there a test plan by module? Note: there is no expectation that this plan would be executed by an independent test lab. The purpose of this checklist item is for the vendor to explain how they test their implementation, and a modular implementation should be testable at the module level. Are the defined interface internally tested by the Product Provider? Is the Modular Architecture able to support testing requirement as described in [TA M] section 7. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 31 / 36 16 Memory Management Shows how the Product manage the memory of the POS System © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 32 / 36 7 APPENDIX A During the evaluation, the Product Provider documentation shall provide enough information on the architecture that will be implemented as well as enough information to address each item in the eligibility checklist. The Product Provider shall provide documentation covering: - The functional specifications of the Modular Architecture - The technical specifications, covering all technical information on how the modular architecture will be (or is) implemented, such as: o All interfaces supported by the Modular Architecture, o All external libraries supported by the Modular Architecture o Memory Management Unit of the Modular Architecture o Configuration Data Management, o Checksum Mechanisms, o … The following outline is the suggested organization of the documentation. 1. Architecture overview. • Which are the modules in this solution and how do they relate to the logical architecture. • From the Eligibility Checklist, how are the Protection Criteria items (1-3) addressed. 2. Module Descriptions: For each module, • Which are the interfaces? (Checklist #7) • Which interfaces to other modules are used? (Checklist #6) • Which are the other external dependencies and under what conditions are these used? (Checklist #4) 3. Version Control: • Which source configuration management processes are used? (Checklist #9). • Within the implementation, how are the module and external dependency versions reported? (Checklist #10). • Does the system recognize unexpected versions? (Checklist #11). 4. Test Processes (Checklist #12). For each module tested in the Contactless Product: • What is the Test Strategy? • What is the Test Plan? 5. Audit Checkpoints. • Provide deployment model. If this does not directly correspond to the architecture model (section1), explain the differences. • How can the audit process: o Verify each module’s implemented interface? (Checklist #8). o Verify each module’s interfaces with the other Modules? (Checklist #6). o Verify each module’s external dependencies? (Checklist #5). © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 33 / 36 © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements 8 APPENDIX B: CHECKSUM RULES Page 34 / 36 The Product Provider shall include in the Product submitted software a checksum computation following the below rules: • Each Kernel Module shall have a unique Checksum. • The Checksum computation of each Kernel Module shall include all requirements of the Kernel Module. • When that the Kernel Module is based on several Software Modules (such as using external routines, librairies, etc), each Software Module shall have a unique Checksum. In that case the Kernel Module Checksum has to be the Checksum computation over all Software Module checksum values. • Any change in a Kernel Module or a Software Module shall generate a new unique Checksum value of the changed Kernel Module or Software Module. • Product Provider shall use an algorithm that generate a unique value each time the module is changed. • The Product shall contain a software mechanism to easily retrieve all checksum values of all Software Modules (librairies, Software Modules, Kernels, Entry Points,…) when these Software Modules are loaded in the Product. When used, this software mechanism shall compute dynamically the Kernels and Entry Points Checksum (not necessary for the Software Modules or librairies). These rules apply whatever the Product follow modular Architecture or not. For a Contactless Product having a Modular Architecture, the following Checksum shall be identified independently. • A Checksum for the Book A & B module, • A Checksum for each Kernel C-1 to C-4 modules, • A Checksum for each test kernels present in the Product. For a Contactless Product having a non Modular Architecture, a unique Checksum shall be idendtified. The below figure gives an example of Checksum coverage. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 35 / 36 In this example, the Full Kernel C-n functionalities are split over a software Kernel C-n Module (blue box) and 3 external librairies/modules (Yellow boxes). Each software module (Kernel C-n, External Librarie 1, External Librarie 2 and External Librarie n) shall have is own unique Checksum. So the Full Module Checksum must be computed over all software module libraries. Same for the Kernel C-m. So yellow external librairies/modules are included in two different checksums. The value of Kernel C-n checksum and the value of Kernel C-m checksum shall be different. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 36 / 36 9 APPENDIX C During the evaluation, the Product Provider documentation shall provide enough information on the architecture that will be implemented as well as enough information to address each item in the eligibility checklist. The Product Provider shall provide documentation covering: - The functional specifications of the Modular Architecture - The technical specifications, covering all technical information on how the modular architecture will be (or is) implemented, such as: o All interfaces supported by the Modular Architecture, o All external libraries supported by the Modular Architecture o Memory Management Unit of the Modular Architecture o Configuration Data Management, o Checksum Mechanisms, o … The following outline is the suggested organization of the documentation. 6. Architecture overview. • Which are the modules in this solution and how do they relate to the logical architecture. • From the Eligibility Checklist, how are the Protection Criteria items (1-3) addressed. 7. Module Descriptions: For each module, • Which are the interfaces? (Checklist #7) • Which interfaces to other modules are used? (Checklist #6) • Which are the other external dependencies and under what conditions are these used? (Checklist #4) 8. Version Control: • Which source configuration management processes are used? (Checklist #9). • Within the implementation, how are the module and external dependency versions reported? (Checklist #10). • Does the system recognize unexpected versions? (Checklist #11). 9. Test Processes (Checklist #12). For each module tested in the Contactless Product: • What is the Vendor Test Strategy? • What is the Vendor internal Test Plan? • How the Vendor internal Test Plan covers the testing of the modularity? 10. Audit Checkpoints. • Provide deployment model. If this does not directly correspond to the architecture model (section1), explain the differences. • How can the audit process: o Verify each module’s implemented interface? (Checklist #8). o Verify each module’s interfaces with the other Modules? (Checklist #6). © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements o Verify each module’s external dependencies? (Checklist #5). Page 37 / 36 © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 38 / 36 10 APPENDIX D: MODULAR ARCHITECTURE FOR TERMINAL WITH SEPARATE CONTACT/CONTACTLESS ARCHITECTURE The present annex describes a specific case of Terminal Architecture that is considered as Modular Architecture. This case covers single box Terminal with a Contact Product and a Contactless Product present onboard. These Contact and Contactless Products are totally separated. This separation applies on the Software and Hardware architecture. So in this architecture there is no common kernel, no libraries shared, no common drivers,…) between Contact and Contactless. In this specific case, the Contact part of the Terminal could be considered as independent from the Contactless part, and therefore the Product has two independent software modules in the Terminal. EMVCo considers this specific case as a Modular Architecture and so this Product could apply for Modular Label where two software modules are present: the Contact Module and the Contactless Module. As for any other Modular Architecture, after granting the Modular Label, all rules applying to Modular Architecture are valid such as: - Software module change or update, - Derivative Product LoA, - … So the two products of the Terminal can change independently from each other. Examples of such architecture could be: - a S-ICR (figure 2 of the present document) where the contact part is in the Terminal (POS System) and no relationship between Reader and Terminal Software (so two separated software architecture). © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 39 / 36 - An ATM where both Contact and Contactless Hardware and Software are strictly separated. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements 11 APPENDIX E: MODULAR CHECKLIST AUDITORS Page 40 / 36 ELIGIBILITY The present annex lists the Eligibility Checklist that an EMVCo recognised Auditor will use during a Modular Audit. The auditor will check the Modularity of the Architecture by verifying the Modular Requirements versus this checklist. 11.1 PROTECTION (PROT) CRITERIA Aspect PROT_1 (Code protection) Code SHALL either be shielded from write access, i.e. it is protected against manipulation in first place or code manipulation SHALL be detected. The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_1a (Code protection) When and how will code manipulation be detected? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_1b (Code protection) What is the reaction in case a manipulation of code is detected? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_2 (Run time data protection) Runtime data SHALL either be shielded from unauthorized access or unauthorized runtime data access SHALL be detected. The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_2a (Run time data protection) When and how will run time data manipulation be detected? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_2b (Run time data protection) What is the reaction in case a manipulation of run time data is detected? Data integrity within transaction processing has always to be guaranteed. The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 41 / 36 Aspect PROT_3 Is persistent data for each module protected from unauthorized access? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_3a When and how will persistent data manipulation be detected? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. PROT_3b What is the reaction in case a manipulation of persistent data is detected? The developer SHALL have a PCI PTS Certificate for each Contactless Product based on the audited Architecture. In Case PCI PTS Certificate cannot be provided (for example case of Contactless Product without PIN Pad), then the developer shall state a test plan for this aspect. 11.2 WELL DEFINED INTERFACES (WELLDEF) Aspect WELLDEF_1 For each module the interfaces SHALL are described in terms of • inputs, • output, and • purpose (reference to the logical architecture is sufficient). WELLDEF_2 Each interfaces SHALL be mapped to the logical architecture. Especially, all interface(s) in the logical architecture SHALL be defined and described. WELLDEF_3 The developer documentation SHALL allow verification of the exact public interfaces of each specific interface provided by the modules. This includes • all public interfaces SHALL be described in the developer documentation and • parameter descriptions SHALL match developer documentation. WELLDEF_4 Check that identified test interfaces are applicable to solely test the intended module. 11.3 WEAK COUPLING (WC) © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 42 / 36 Aspect WC_1 For each module, all external dependencies SHALL be documented, including version and specific functionality used in the External Dependency. The developer SHALL state a test plan for this aspect. WC_2 No undocumented external dependency SHOULD exist. The developer SHALL state a test plan for this aspect. WC_3 How is the External Dependency distributed, i.e. how does it get into the product? WC_4 For each external dependency it SHALL to be described if it is part of the platform OS or the Payment Application. WC_5 It SHALL be address how potential code optimizations performed by most compilers are prevented. The developer SHALL state a test plan for this aspect. 11.4 VERSION MANAGEMENT (VM) Aspect VM_1 The Configuration Management system used SHALL be stated if any. It SHALL be stated which items are controlled by the CM. It SHALL be described how configuration items are linked to different product versions. It SHALL be described how the CM system is integrated into production and development process. It SHALL be described which which roles and responsibilities are defined in the CM system. It SHALL be described which activities on configuration items are subject to CM procedures (Creation, modification, deletion). It SHALL be described which roles/individuals are authorized to make changes to configuration items. It SHALL be described who grants access rights. It SHALL be described which procedures are applied for checking and releasing components and the TOE before operation. VM_2 The modular architecture SHALL uniquely identified by - Architecture type (Overall modular, with external dependencies) © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Page 43 / 36 - version, and - date Aspect VM_3 All modules SHALL be uniquely identified by - name, - version, - date and - checksum VM_4 For a specific module implementation, it SHALL be possible to report the exact source code versions used to build the module. VM_5 For a product in the field, identification and verification of the the version of each module SHOULD be possible. The developer SHALL state a test plan for this aspect. VM_6 For a product in the field, identification of the version of each External Dependency SHOULD be possible. VM_7 The modules SHOULD check the versions of its External Dependencies. The developer SHOULD state a test plan for this aspect. If applicable: How do modules behave in case an External Dependency does not match the expected version? If applicable: Check if a module runs with unexpected version of an External Dependency. 11.5 TESTABILITY (TEST) Aspect TEST_1 For each module, a strategy for independently test each module SHALL be given. TEST_2 The developer SHALL state whether the defined interfaces are internally tested by the Product Provider. TEST_3 The Modular Architecture SHALL be able to support testing requirement as described in [TAM, section 7]. 11.6 MEMORY MANAGEMENT (MM) © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is EMV® Terminal Type Approval Contactless Product Modular Requirements Aspect MM_1 The developer SHALL state how the product • manages, • reserves and • allocates the memory of the POS system? Page 44 / 36 11.7 SOFTWARE MANAGEMENT (SWM) Aspect SwM_1 The developer SHALL state how the product ensures changing the underlying platform does not affect the product. © 2017-2025 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is