TTA Bulletin nº 11: Major Minor Change Definitions

EMV^® Terminal Type Approval Bulletin No. 11 10th Edition June 2021 Major and Minor Change

Definitions

Applicability

This Bulletin applies to:

• All Terminal Approval processes

Effective Date

• Immediate

Description

Changes to an approved component will be considered major or minor in nature based upon the impact to the approved component. When a change to an approved component is considered major, the new component is no longer linked to the original approval and requires the vendor to submit the new component for Type Approval testing to receive EMVCo approval. If a change to an approved component is considered minor, there is no retesting required by EMVCo. However, it should be noted that EMVCo does not issue approval letters to these derivative Products. It is the vendor’s responsibility to manage all linkage, documentation or test results to the new component to show this is a derivative of the original approval. As vendors are intimately familiar with their developed components (IFM or Kernel), it is ultimately the vendor’s responsibility to make the determination whether a change to their approved component is major or minor. However, if the vendor is unsure of the severity of the change, they may submit details of the change to EMVCo via email to request EMVCo's opinion. This request should include a full description of the change being made by the vendor in order for EMVCo to make a timely assessment.

countries.

Proximity Coupling Device (PCD) Most changes to a PCD are classed as major changes. The list below provides some examples of PCD changes; please note this list is not meant to be exhaustive. As stated above, it is the vendor’s responsibility to determine if the change to the PCD is major or minor. However, anything that significantly impacts or affects the functionality of the PCD must be considered a major change. Examples of major Changes

• Change in the way the Contactless EMV specification is implemented (see ICSimplementation information)
• Addition or modification of functionalities (e.g. adaptation to new OS, support of new technologies or protocols...)
• Change of Proximity Payment Antenna location or design.
• Change to an equivalent or different processor (in the situation where the processor is dedicated to the PCD, otherwise this change has to be considered a change of the environment).
• Contactless Controller firmware changes impacting L1 performance
• PCD software or firmware changes impacting L1 performance
• Contactless Controller hardware change
• Contactless Controller parameter changes
• PCD Landing Plane change
• Contactless Symbol position change
• PCD Casing changes involving metallic characteristics
• Component or PCB changes impacting L1 performance Examples of minor Changes
• Change of passive or active components for another with same physical and electrical characteristics.
• Change of the color or marking of the PCD enclosure
• Change of an external connector
• Different providers implementing same antenna design and material (antenna design is exactly the same – shape, thickness, material etc.) Interface Modules (IFM) Most changes to an IFM are classed as major changes. The list below provides some examples of IFM changes; please note this list is not meant to be exhaustive. As stated above, it is the vendor’s responsibility to determine if the change to the IFM is major or minor. However, anything that significantly impacts or affects the functionality of the IFM must be considered a major change. Examples of major changes
• Change of firmware
• Change of contacts
• Change of clock crystals
• Change of PCB layout countries. Examples of minor changes
• Change of connector
• Change of transistor
• Change of capacitor/resistor Minor changes to the IFM Please note that the above examples of minor changes may or may not qualify as a minor change. This will depend on the nature of the change and the impact to the IFM. Application Kernel Since the application kernel is software related, changes can be made that directly involve the interface with the application kernel. Such changes might include parameter settings of the kernel, or to the operating system itself. These changes can rate major or minor depending on the software architecture of the kernel. This list below provides some examples of application kernel changes; please note this list is not meant to be exhaustive. As stated above, it is the vendor’s responsibility to determine if the change to the application kernel is major or minor. However, anything that significantly impacts or affects the functionality of the application kernel must be considered a major change. Examples of major changes
• Change of operating system (see below)
• Any change to the CVM Capability (Plaintext PIN for ICC Verification, Enciphered PIN for online Verification, Signature {paper}, Enciphered PIN for offline Verification, No CVM required)
• Any modification to the Data Authentication capabilities (SDA, DDA, CDA)
• Adding, removing, or changing the following Transaction Types: Cash, Goods, Services, Cashback, Purchase, Refund, Purchase with Cashback, Cash Advance
• Loading new, or removing all, Issuer Code Table Indexes
• Adding or removing PSE, Cardholder Confirmation, or Preferred Order of Display
• Any modification to the methods used Issuer Public Key revocation
• Adding or removing default DDOL
• Adding Magnetic Stripe Reader
• Changing Magnetic Striper Reader from a combined to a non-combined type
• Any change to the Cardholder Verification methods (Bypass PIN Entry, Get Data for PIN Try Counter, Fail CVM, Amount known before CVM processing)
• Adding or removing Terminal Risk Management functions (Floor Limit Checking, Random Transaction Selection, Velocity Checking, Transaction Log, Exception File)
• Adding or removing Terminal Action Code support
• Modifying the timing (before or after first Generate AC) for Default Action Codes
• Adding, removing, or changing Completion Processing (Forced Online, Forced Acceptance, Support Advices, Referral Support, Batch Data Capture, Online Data Capture, Default TDOL)
• Recompiling the application kernel
• Adding/changing a Currency Code (if only one Currency Code has been declared in ICS and tested)
• Adding a New Currency Code with an untested Currency Exponent (if one or multiple Currency Code has been declared in ICS and tested)
• Adding/changing a Language (if only one Language has been declared in ICS and tested) countries. Examples of minor changes
• Update to operating system (see below)
• Adding/removing a Currency Code (only if at least two currency codes have been declared in ICs and tested) if the added currency code is not introducing a new currency exponent.
• Update to Application Version Number
• Modification of Terminal Currency Code
• Adding, removing, or changing Manual Key Entry functionality
• Removing, or changing Magnetic Stripe Reader (same type of reader)
• Changing Magnetic Striper Reader from a non-combined to a combined type
• Replacing the IFM with another approved module
• Adding, removing, or changing Card Capture features
• Adding, removing, or changing the following Transaction Types: Inquiry, Transfer, Payment, Administrative
• Any modification to the Terminal Data Input Capabilities (Numeric Keys, Alphabetic and Special Character Keys, Command Keys, Function Keys)
• Adding, removing, or changing Printer or Display hardware
• Modification to previously loaded Issuer Code Table Indexes
• Modification to the POS Entry Mode A sample level 2 implementation conformance statement is provided below, illustrating those options that relate to major or minor changes. Contactless Product All major and minor changes described above in the present document are applicable for Contactless Product. Additional changes related to Contactless Product specifically exist as per the below examples: Examples of additional major changes specific for Contactless Product
• Terminal Capabilities change
• Addition or removal of functions (Pre processing, CVM, …)
• For C-3 only:
• Adding or removing Magnetic Stripe Reader
• Adding/changing a Currency Code (if only one Currency Code has been declared in ICS and tested)
• Adding a New Currency Code with an untested Currency Exponent (if one or multiple Currency Code has been declared in ICS and tested) Examples of minor changes
• Adding/removing a Currency Code (only if at least two currency code have been declared in ICs and tested) countries. Terminal Type Changes to terminal type may, or may not, qualify as major change. This depends on the nature of the change: 1. Change of operational control (financial institution, merchant, or cardholder) with no other changes may be considered minor, if the terminal type value is a parameter and falling within one of these combinations:
• Financial Institution controlled to attended, assuming the original Financial Institution implementation prompted for amount entry when Amount, Authorized is not available following a PDOL request.
• Financial Institution controlled to Cardholder controlled, assuming Terminal Risk Management remains supported and no change to the Magnetic Stripe Reader interface.
• Attended to Financial Institution controlled, assuming the original Merchant implementation prompt for amount entry when Amount, Authorized is not available following a PDOL request remains supported.
• Attended to Cardholder controlled, assuming Terminal Risk Management remains supported and no change to the Magnetic Stripe Reader interface.
• Cardholder controlled to Financial Institution controlled, assuming the original Cardholder implementation supported Terminal Risk Management and a Magnetic Stripe Reader interface.
• Cardholder controlled to attended, assuming the original Cardholder implementation prompted for amount entry when Amount, Authorized is not available following a PDOL request, supported Terminal Risk Management and a Magnetic Stripe Reader interface. 2. Change of environment (attended or unattended) is always considered as a major change. 3. Change of capabilities (offline or online) is always considered as a major change. Note: That when supporting Terminal Type '12', '22', '15', or '25' (offline with online capability), setting the Terminal Floor Limit to zero and the corresponding TAC-Online bit to 1 shall not be considered identical to Terminal Type '11', 21, '14', or '24' (online only). However, such a configuration change will behave similarly to an online only Terminal Type. As the configuration change is only to the TAC’s, this is neither a major or minor change 4. By default, all other terminal type changes shall be considered as major. Operating Systems Changes to an application kernel’s operating system may, or may not, qualify as a major change. This depends on the nature of the change. Application kernels may reside on commercially available operating systems, such as Windows XP, NT, or Linux. In this type of environment there are two basic changes that can occur. countries. 1. Updating an existing operating system. An example of this would be the NT operating system updating from service pack 4 to service pack 5. A commercial operating system update is generally considered a minor change. However, it is the vendor’s responsibility to ensure such a change does not significantly impact the interface or functionality or the application kernel. If the application kernel is significantly impacted this would be considered a major change. 2. Porting from one commercially available operating system to another. For example, porting an application kernel from Windows 98 to Windows XP, porting from Linux to Windows NT, or from a proprietary operating system to a commercial operating system are all major changes, and the application kernel would require new Type Approval to maintain EMVCo approval. Finally, an application kernel may reside on a proprietary operating system. As EMVCo has no familiarity with these proprietary operating systems it is the vendor’s responsibility to determine whether changes are major or minor in nature. However, should any change to a proprietary operating system significantly impact the interface or functionality of the kernel it is considered a major change. In addition, porting from one proprietary operating system to another is also considered a major change. Combining of Approved IFMs and Application Kernels IFMs and Application Kernels are approved as independent functional components, it may be considered a minor change to combine previously approved components that may never have been used in combination before -- including components that may have been developed according to different versions of the EMV specification. For example, it is possible use an EMV 3.1.1-compliant IFM in conjunction with an EMV 4.0-compliant application kernel provided that the combining of components did not require additional modifications that could negatively impact the functionality of either component. If an IFM and application kernel can be combined without requiring any of the modifications categorized as major for each component, then the process of combining the components could be considered a minor change. PIN Pads Changes to an approved device may also impact the PIN Pad itself. These changes follow our major and minor procedures as outlined above, if the change significantly impacts kernel or IFM functionality the change would be classed as major. If the change does not significantly impact the kernel or IFM the change would be classed as minor. The EMV kernel typically falls into one of four basic categories, in regards to Terminals utilizing PIN Pads. The following possibilities may exist:
• The kernel exists entirely within the Terminal/POS device and the attached PIN Pad does not contain the IFM but serves only for the purposes of PIN entry. In this scenario the PIN Pad is terminal dependent, simply passing PIN related data but providing no kernel functionality. In this environment changes to the PIN Pad are considered minor as none of the EMV kernel functionality exists in the PIN Pad. However, changes to the PIN Pad in this environment may impact the IFM itself, as described above. countries.
• The kernel exists entirely within the Terminal/POS device and the attached PIN Pad only contains the IFM. In this scenario the PIN Pad is terminal dependent, simply passing PIN related data but providing no kernel functionality. In this environment changes to the PIN Pad are considered minor as none of the EMV kernel functionality exists in the PIN Pad. Changes to the PIN Pad in this environment may impact the IFM itself, as described above.
• The kernel is split between the Terminal/POS device and the PIN Pad. In this scenario, core functions of the kernel, such as Data Authentication or CVM Processing, is processed by the PIN Pad while all other kernel functionality is performed by the Terminal/POS. In this environment, it is important to note that both portions of the kernel within the Terminal/POS and PIN Pad make up the entire kernel and are approved as a single kernel. If the vendor makes changes to, or replaces either, it would be considered a major change. Changes to the PIN Pad that effect the IFM fall under the rules outlined above for major or minor consideration.
• The kernel exists entirely within the PIN Pad and may be attached to a Terminal/POS device. In this scenario, the Terminal/POS provides a point of input for the PIN Pad to complete the transaction, such as the amount entry or IC contacts. Otherwise, the PIN Pad performs all EMV kernel functionality. In this environment, changes to the PIN Pad that effect the EMV Level 2 kernel may be considered major based the rules outlined above. Changes to the Terminal/POS would generally be considered minor, as none of the EMV Level 2 functionality exists within the Terminal/POS. Changes to the PIN Pad that effect the IFM fall under the rules outlined above for major or minor consideration. countries. The following level 2 ICS outline provides an example of the level of impact when applying changes to an approved kernel. However, these definitions are examples only. It is the vendor's responsibility to determine the level of impact for any change. Some changes listed below as minor may in fact be major changes, based on a specific implementation. PART V – Terminal Details Terminal Capabilities Card Data Input Capability Manual Key Entry Magnetic Stripe IC with Contacts CVM Capability Plaintext PIN for ICC Verification Enciphered PIN for online Verification Signature (paper) Enciphered PIN for offline Verification No CVM Required Does the Kernel support the SB 185 - Biometric Terminal Specification? If yes the kernel shall support minimally the SB185 requirements: - the values in range 000110-001111 of the Book3, Table 39 - CVM Codes are considered as recognized values for unsupported Biometric CVM Codes - the Kernel implements the updated flow ‘T’ of the figure 9 in SB185 - Biometric Data Objects as per Annex A1 of SB 185 are recognized by the Kernel, If no the kernel shall not support any SB185 requirements (the values in range 000110-001111 of the Book3, Table 39 - CVM Codes are considered as RFU) Value Supported Minor Major Major If Biometric supported, does the Kernel support Finger biometric verified offline (by ICC)? If Biometric supported, does the Kernel support Finger biometric verified online (by ICC)? Major Major countries. If Biometric supported, does the Kernel support Facial biometric verified offline (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Facial biometric verified online (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Palm biometric verified offline (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Palm biometric verified online (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Iris biometric verified offline (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Iris biometric verified online (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Voice biometric verified offline (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If Biometric supported, does the Kernel support Voice biometric verified online (by ICC)? Note: This Biometric CVM is not supported for approval and testing in this version. In case your Product support it, please contact EMVCo If One of the Biometric CVM is supported, what is the Biometric Data Block Maximum Length supported? NA NA NA NA NA NA NA NA Major countries. Security Capability Static Data Authentication and Dynamic Data Authentication (Mandatory for offline capable terminals) Card Capture Combined Dynamic Data Authentication / Application Cryptogram Generation (if CDA is supported it shall support one of the 4 modes described in AN41) Major Minor Major countries. Additional Terminal Capabilities Transaction Type Capability At least one of the following transaction types must be supported: Cash Goods Services Cash Back Inquiry Transfer Payment Administrative Cash Deposit Value Supported Major Minor Terminal Data Input Capability Does terminal have a keypad (If keypad is supported the terminal shall support one or more of the following key types:) Numeric Keys Alphabetic and Special Character Keys Command Keys Function Keys Minor Terminal Data Output Capability Print, Attendant (Mandatory for terminals supporting signature) Print, Cardholder Display, Attendant (Mandatory for Attended terminals) Display, Cardholder Code Table 10 Code Table 9 Code Table 8 Code Table 7 Code Table 6 Code Table 5 Minor If value of supported table changed: minor If removing all the supported tables or indicating one as supported when countries. Code Table 4 Code Table 3 Code Table 2 Code Table 1 previously none were: Major Application Selection How Many AID with the associated set of data (such as TAC, etc) can be supported by the Application Kernel? Support PSE selection Method Support Cardholder Selection & Confirmation Does Terminal have a preferred order of displaying applications Does terminal perform partial AID selection Does the terminal have multi language support Does the Terminal support the EMV Language Selection method Does the terminal support the Common Character Set as defined in Annex B Table 20 Book 4 Value Supported Minor if Multiple AID already supported Major Minor if Multiple Language already supported Selectable Kernel Configurations (MCK only) Is your Multi-Configuration Kernel capable of dynamically selecting a configuration at the time of transaction Value Supported Minor Data Authentication What is the maximum supported Certificate Authority Public Key Size (Mandatory for terminals supporting Data Authentication with minimal support for 248 bytes) What exponent does the terminal support (Mandatory for terminals supporting Data Authentication, 3 and 216 + 1) During data authentication does the terminal check validity for revocation of Issuer Public Key Certificate When supporting certificate revocation, what is the Certificate Revocation List format? (CRL format must include: RID, CA Public Key Index, Certificate Serial Number, and optional additional data) Value Supported Major countries. Does the terminal contain a default DDOL (Mandatory for terminals supporting DDA) Is operator action required when loading of CA Public Key fails CA Public Key verified with CA Public Key Check Sum (If no, provide a description of the method used to validate the CA Public Key when loaded in the Comments and Explanations Section) Cardholder Verification Method Terminal supports bypass PIN Entry If the terminal supports bypass PIN Entry: When selecting to bypass a PIN method, all other PIN entry methods are also considered bypassed. Terminal supports Get Data for PIN Try Counter Terminal supports Fail CVM Are amounts known before CVM processing Value Supported Major Terminal Risk Management Floor limit checking (Mandatory for offline only terminals and offline terminals with online capability) Random Transaction Selection (Mandatory for offline terminals with online capability, except when cardholder controlled) Velocity Checking (Mandatory for offline only terminals and offline terminals with online capability) Transaction Log Exception File Performance of Terminal Risk Management irrespective of AIP setting (expected behavior) Value Supported Major countries. Terminal Action Analysis Does the terminal support the Terminal Action Codes (If the answer is no, please contact EMVCo) Can the Terminal Action Codes be deleted or disabled? If yes what are the default TAC values supported (according to Book 3 Section 10.7? If Offline Only is supported, which option of the Offline Only Terminal processing is implemented? (according to SB 209) If Online Only is supported, how does online only terminal process TAC/IAC-Default when unable to go online? Value Supported Major Completion Processing Transaction Forced Online Capability Transaction Forced Acceptance Capability Does terminal Support Advices Does the terminal support Issuer initiated Voice Referrals Does the terminal support Batch Data Capture Does the terminal support Online Data Capture Does the terminal support a Default TDOL If a Default TDOL is supported, can this default TDOL be not configured (or not loaded) in the terminal Is the Default TDOL TVR bit set before or after the 1st Generate AC Terminal Action Analysis? (Note: When applicable, the setting/unsetting of the Default TDOL TVR bit according to the Default TDOL usage is always performed prior to the 1st Generate AC. However this TVR bit only impacts the 1st Generate AC TAA if it is set before the 1st Generate AC TAA is performed) Value Supported Major Exception Handling What is the POS Entry Mode value when IC cannot be read and the transaction falls back using Magstripe Value Supported Minor countries. Miscellaneous Is the terminal equipped with a PIN Pad Is the amount and PIN entered at the same keypad Is the ICC/Magstripe Reader combined If Combined ICC/Magstripe Reader is supported, is Magstripe read first Does the terminal support account type selection Does the terminal support ‘on fly’ script processing (not recommended behavior) Is the Issuer Script device limit greater than 128 bytes If the Issuer Script device limit is greater than 128 bytes, what is the value supported (If unlimited please enter 0) Does the terminal support Internal Date Management (If the kernel is capable of managing the increment of dates internally without synchronization or instruction from the host, ‘Yes’ should be selected for this option) Is the Level 2 Contact Kernel Random Generator using the algorithm described in SB144 (Terminal Unpredictable Number generation) If the Level 2 Contact Kernel Random Generator is not using the algorithm described in SB144, is this function PCI approved? If the Level 2 Contact Kernel Random Generator is not using the algorithm described in SB144, describe the function (such as algorithm used, etc) Is the Random Generator function of the Level 2 Contact Kernel Software dependent on the Terminal Hardware? If answer to previous question is Yes, describe the Hardware (a clear description of the chipset is required) Are the Cryptographic functions (RSA, Hash, etc) of the Level 2 Contact Kernel Software dependent on the Terminal Hardware? If answer to previous question is Yes, describe the Hardware (a clear description of the chipset is required) Is any other functions of the Level 2 Contact Kernel Software dependent on the Terminal Hardware? If answer to previous question is Yes, describe the functions and the Hardware (a clear description of the chipset is required) If the answer to at least one of the 6 previous questions is Yes, do you plan to port the Kernel to other Terminals having the same Hardware component supporting these above functions (Family of Terminal)? Value Supported Major Minor Major Minor Minor Major countries. Does the terminal support Receipt (by printing or any electronic means)? Does the Terminal store declined transactions? List the Currency Codes supported as for ISO 4217 (minimum one shall be declared) Does the terminal support the Application Selection Registered Proprietary Data (ASRPD)? List the Language(s) supported as for ISO 639 (minimum one shall be declared, and up to 4 if Multiple Languages are supported) Can the Kernel be configured so the data object ‘Terminal Risk Management Data’ ‘9F1D’ is absent or configured with no value (00 is a value)? Can the Transaction Sequence Counter (TSC) be personalized to any value? If answer to previous question is Yes, what is the Maximun Value of the Transaction Sequence Counter? Minor (If More than one Currency already supported) Major Minor (If More than one Language already supported) Major Major Major Checksum Does the product comply with the Checksum rules as defined in Contact Terminal Level 2 administrative process If answer to previous question is No, the following question must be checked Yes: - This is an Initial submission or Subsequent submission or renewal of the original approved product prior to the effective date of checksum rules (cf Terminal Type Approval Bulletin No. 134) Configuration Checksum (Static Kernel only) Value Supported Major countries.

Legal Notice

This document summarizes EMVCo’s present plans for evaluation services and related policies and is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document.

countries.