EMV® Level 3 (L3) Technical Bulletin n° 321 - Comment period ends 24 June 2026

EMV® Level 3 Technical Bulletin No. 321 First Edition, June 2026 EMVCo Level 3 Framework Implementation Guidelines Updates EMVCo Level 3 Pseudo-Function Definitions for Test Card Images Updates Applicability This Bulletin applies to: • EMVCo Level 3 Solutions and Service Providers, including (but not limited to): o Suppliers of Level 3 test tools o Entities performing L3 test tool qualification testing on behalf of EMVCo Related Documents • EMV® Level 3 Testing Framework Implementation Guidelines – Version 1.3.r (dated October 2025). • EMV® Level 3 Testing Framework Pseudo-Function Definitions for Test Card Images - Version 1.6 (dated March 2023) Effective Date • Immediately Description Since publication of the EMV L3 Testing Framework Implementation Guidelines – Version 1.3.r document in October 2025 and EMV L3 Testing Framework Pseudo-Function Definitions for Test Card Images – Version 1.6 document in March 2023, feedback has been received by EMVCo. This EMVCo Level 3 Bulletin provides details of updates, clarifications and corrections required to the L3 EMV® Level 3 Testing Framework Implementation Guidelines – Version 1.3.r (dated October 2025) and L3 EMV® Level 3 Testing Framework Pseudo-Function Definitions for Test Card Images - Version 1.6 (dated March 2023). Impacted components: L3TSE, L3TT and L3CS © 2026 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. Page 1 Details of the Changes A. Partial AID selection update .......................................................................................................... 3 B. TSE Test Session files update clarification ................................................................................... 4 C. Clarifications for FIND & LOG_RESET ......................................................................................... 4 D. Read Record clarification .............................................................................................................. 5 E. Clarification for optional Checksum in TSER ................................................................................ 5 F. Clarification for emvcard.atc() pseudo-function value ................................................................... 5 G. Clarification for Card Simulator form factor ................................................................................... 5 H. Clarification for emvcard.CardTVR() pseudo-function value......................................................... 5 I. Clarification for emvcard.AC() pseudo-function ............................................................................ 5 J. Clarification for Mode value in TestRunInfo.xml............................................................................ 6 K. Clarification for DA attribute in Card Terminal log Format ............................................................ 8 L. Correction of and tags occurrence in Selected.xml........................................ 8 M. Correction and clarification for emvcard.sdad() pseudo-function description ............................. 10 N. Clarification for unknow data ....................................................................................................... 11 O. Clarification for Get Challenge and Verify commands ................................................................ 11 P. Clarification for Card Risk Management...................................................................................... 12 Q. Clarification for Padding .............................................................................................................. 13 R. Clarification for Empty record ...................................................................................................... 13 S. Clarification for Issuer Script Commands .................................................................................... 13 T. Correction of examples for Table A.33: APDU DataItem Format ............................................... 13 U. Clarification for Table 4.20: TestRun file format .......................................................................... 14 V. Clarification for the display of multiple question with different context........................................ 14 W. Clarification for the format of SFI and Record Number ............................................................... 15 X. Clarification for the display of Check and Step of Check in UI.................................................... 15 Document updates : - Blue highlights existing text with areas of addition or change. - Strike red highlights existing text to be deleted. © 2026 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. Page 2 A. Partial AID selection update The L3CS 1.10 requirement is updated as follows. L3CS 1.10 Select Application M If the application needs to respond, the command shall be present in the image definition. The application shall support Select Next and Select for blocked application. The application shall support partial AID selection, using the RID (5 Bytes) as minimal match, unless the PartialMatchLength parameter is defined in the xml tag in the card image. If the PartialMatchLength parameter is present, the application shall support partial AID selection, using the PartialMatchLength parameter as minimal match. Table 4.23: An optional attribute is added for definition in Test Card Image Format. Field Block/Tag/Attribute M/O/C Occurrence Description and Requirement . or Block-start O 0..2 Block which specifies zero or more contact or contactless application(s). Dual Interface card used in Terminal testing can be specified in a single XML file. .. Block-start O 0..n An application is made of one or more terminal request(s). ..AID Attribute M 1..1 Application Identifier - e.g., AID = "32 50 41 59 2E 53 59 53 2E 44 44 46 30 31”. Hexadecimal tag or attribute data can be coded with or without spaces. ..cryptoId Attribute O 0..1 Optional attribute cryptoId refers to keys in crypto block below. If no cryptoId is specified, then the application uses the first crypto block specified in the definition. ..PartialMatchLength Attribute O 0..1 Optional attribute used for Partial AID Selection. If not present, refer to L3CS 1.10 requirement. ... Block-start M 1..n A terminal request holds one card response. Logic is driven by the combination of cmd-ins-p1-p2-cmdData. Values not present are wildcards. © 2026 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. Page 3 B. TSE Test Session files update clarification The L3TSE 14.4 requirement is updated as follows. L3TSE 14.4 • L3TSE updates the TSE Test Session files: M - Update ChangeFlagDate in TestRunInfo.xml. - If the user decides to overrule previous test results, then completely refresh TestRun.xml as described in 4.2.3. - If the user decides to keep previous test results, then update TestRun.xml. i. Remove all Test Cases (including , and ) that are "Not executed" and no longer applicable (not in scope). ii. Add Test Cases that are applicable and not yet in the TestRun.xml. iii. If the MODE_Regression indicator is set, then put status to "Not executed" for all Test Cases that have isRegression set to Yes in RuleSet.xml. Optionally the tool can warn the user that this is going to happen. iv. Remove all that are no longer applicable (not in scope). - Completely refresh Selected.xml as described in 4.2.4. C. Clarifications for FIND & LOG_RESET As defined in table 4.22 Tool Pass/Fail Automation Criteria syntax, the “find” operator is used to instruct tools to search forward and find the first instance of a network message or APDU where the data item is equal to the value provided in the value field. The search starts at the beginning of the log. The value field must be a fixed value; wildcard characters are not allowed. The LOG_RESET value is used to reset the processing to the beginning of the log. Any subsequent pass criteria will apply to the first instance of a network message or APDU transaction. Only one APDU log per card and one NETWORK log shall be attached to a test case. These logs can contain multiple transactions. The L3 TT tool shall evaluate the pass criteria with all logs attached to a test case starting with the first attached log. © 2026 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. Page 4 D. Read Record clarification In Section 3.4.1, the 1st paragraph is updated as follows. If tag '9F2B' is requested in PDOL and byte 1 of tag '9F2B' sent in GPO command is not equal to '00', then Kernel 8 is detected and the L3 CS will select the first most restrictive matching tag which must include an attribute kernelID=08 (if available). The “kernelID” attribute was introduced to identify C-8 transaction path (with kernelID=08). An xml test card image would not be able to use the kernelID attribute in a tag prior to the GPO as the L3 CS would not have access to the Kernel Qualifier requested in the PDOL. For the C-8 transaction path, this attribute is mandatory for GET PROCESSING OPTIONS command and GENERATE AC command because the data in these commands (‘cmdData’ attribute) are specific to C-8 transaction path or non-C8 transaction path. The “kernelID” attribute is not intended for use in other commands. Both C-8 and non-C8 profiles can use the same READ RECORD command/answers for unencrypted record. For encrypted data (with tag DA), the READ RECORD command must be used specifically for C-8 transaction path. A non-C8 profile must not include this encrypted READ RECORD command/response. Table 3.4: Example of L3 card image below includes an example implementation of requirement L3CS 7.4. E. Clarification for optional Checksum in TSER For data integrity checking purpose, the TSER file may optionally include a checksum on the last line of the file. The Level 3 TSE component can ignore or validate the checksum. If the validation fails, a warning may be displayed, and tool shall continue the processing. TSER file example with checksum: … F. Clarification for emvcard.atc() pseudo-function value The value provided by the emvcard.atc() pseudo-function is independent of the value defined in GETDATA command and/or in internal tags. Vendor can optionally link the value of emvcard.atc() pseudo-function to GETDATA and/or internal tag definition. G. Clarification for Card Simulator form factor In Section 4.5, the 1st paragraph is updated as follows. This part of the guidelines describes the EMVCo Level 3 Card Image definition for Test Card Simulation (L3 Card Simulator- L3CS) using Programmable Cards or, Probes or any other form factor. H. Clarification for emvcard.CardTVR() pseudo-function value The value parameter is a 5-bytes mandatory data. I. Clarification for emvcard.AC() pseudo-function If the Amount (Other) - 9F03 value is NOT present, the emvcard.AC() calculation shall use an amount equal to zero. The Terminal Verification Results (tag ‘95’) value must be replaced by the CardTVR (tag '9F8104’) value if the Card TVR data is sent in GenerateAC command response (refer to requirements in emvcard.CardTVR() pseudo function definition). © 2026 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. Page 5 J. Clarification for Mode value in TestRunInfo.xml Find below a table that summarises the requirements for L3TSEFIGVersion and L3TTFIGVersion depending on Mode in TestRunInfo.xml. Step Mode in TestRunInfo.xml L3TSEFIGVersion Comments L3TTFIGVersion Comments Context presence Presence 1 MODE_Question Mandatory If L3TSE updates the Empty or Tag Not Not applicable TestRunInfo.xml file, present created by L3 TSE L3TSEFIGVersion must be updated by the version of the tool. 2 MODE_Info Mandatory If L3TSE updates the Empty or Tag Not Not applicable TestRunInfo.xml file, present created by L3 TSE L3TSEFIGVersion must be updated by the version of the tool. 3 MODE_TestResult (all Mandatory If L3TSE updates the Can be present If L3TTFIGVersion is TestRunInfo.xml test cases are not tested) file, present, it must not be created by L3 TSE L3TSEFIGVersion removed, and it can be must be updated by updated by the version of the version of the the tool. tool. 4 MODE_Regression (all Mandatory L3TSEFIGVersion Can be present If L3TTFIGVersion is File updated by L3 test cases are not tested) must be updated by present, it must not be TSE the version of the tool removed, and it can be because one updated by the version of question with the tool. regression mode has been updated. 5 MODE_TestResult (some Mandatory No change required. Mandatory L3TTFIGVersion must be File updated by test cases have been updated by the version of L3TSE or L3 TT executed) the tool. © 2026 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. Page 6 6 MODE_Regression (some Mandatory test cases have been executed) L3TSEFIGVersion must be updated by the version of the tool because one question with regression mode has been updated. Mandatory L3TTFIGVersion must be updated by the version of the tool. File updated by L3TSE or L3 TT © 2026 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. Page 7 K. Clarification for DA attribute in Card Terminal log Format Table 4.24: DA attribute description for in Card Terminal log Format is updated as below. Field Block/Tag/Attribute M/O/C Occurrence Description and Requirement ... Block-start O 0..n Zero or more Command Response blocks. .... Tag M 1..1 Either a command APDU or an event literal – e.g., "EVENT_POWER_ON". .... Tag O 0..1 Integer providing the time in milliseconds at which the command was sent or the event occurred. This time may be relative to system time, UTC or to a timer which is initialised at the beginning of testing, whichever is convenient for the logging tool. CommandTimestamp is not mandatory for Tools that do not have a timer and therefore unable to support time stamps. .... Tag M 1..1 Response APDU sent by the card or the response of the card to the event defined by the command. May be empty for some commands. ....DA Attribute C O 0..1 An optional attribute DA shall can be added to the tag if the response is encrypted (DA) as defined in the contactless Kernel 8 specification. The value shall match the encrypted value of Tag in TLV format e.g., DA="DA8195AABBCC…” .... Tag O 0..1 Integer providing the time in milliseconds at which the response was received from the card. Must use the same timer as the command timestamp. This element may be empty for some of the events as described below. Response Timestamp is not mandatory for Tools that do not have a timer and therefore unable to support time stamps. ... Block-end L. Correction of and tags occurrence in Selected.xml Table 4.21 is updated as follows. Table 4.21: Selected file Format © 2026 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. Page 8 Field file_version originator updatedby . .. ... Block/Tag/Attribute Tag Block-start Attribute Attribute Attribute Block-start Block-start Tag M/O/C M M M M O M M M Occurrence 1..1 1..1 1..1 1..1 0..1 1..n => 1..1 1..1 => 1..n 1..1 Description and Requirement xml version and encoding e.g., XML root node. Version of the format definition. Name of L3TSE tool generating the file. Name of L3TSE tool updating the file. List of the test cases that TSE has defined in Test Session scope. Individual entry. From RuleSet XML: . © 2026 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. Page 9 M. Correction and clarification for emvcard.sdad() pseudo-function description For the L3 Card Simulator (L3 CS) component only, the following requirement in purple for supporting XDA is for future proofing purposes only. Vendors may choose to implement it. However, it will not be tested, nor will it be part of the L3 CS qualification. The emvcard.sdad() pseudo-function description is updated as follows: Signed Dynamic Application Data for XDA, DDA, CDA or fDDA. GenAC: is used when CDA or XDA supported. The logic is defined as follows: if (P1==???1????b) [CDA requested], then Signed Data Format (SDF) value used to generate SDAD = '05' else if (P1==????1???b) [XDA requested], then SDF value used to generate SDAD = '15' else tag ’9F26’ (AAC AC cryptogram) returned Internal Auth: emcard.sdad() is used when DDA supported. SDF value used to generate SDAD = '05'. Contactless GPO or in READ RECORD: emvcard.sdad() is used when fDDA supported. SDAD is generated as follows: if (Card) CID = 'TC', then SDF value used to generate SDAD = '05' else if (Card) CID = 'ARQC' and TTQ bit 'ODA for online authorisations supported' = 1b, then SDF value used to generate SDAD = '95' format 'A5' and ’05’ SDF may be used by Participant Systems. © 2026 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. Page 10 N. Clarification for unknow data The L3TSE 1.1 requirement is updated as follows. L3TSE 1.1 • L3TSE shall be able to import the csv files with data field names in headers presented in any order and ignore any unknown data M field names. header as defined in Manifest.tricm file. The L3TSE 1.2 requirement is created. • L3TSE should be able to import any manifest.tricm file with tag L3TSE 1.2 names presented in any order and ignore any unknown tag M name. O. Clarification for Get Challenge and Verify commands The L3TSE 1.4 requirement is updated as follows. Get Challenge and Verify Get Challenge shall respond using Tag if present in the card L3CS 1.4 iVmeargifey.cIof mtamg aisnndosthdaellfionneldy, vthaelidcaatredthsiemPuIlNatoVrasluhealilfuthsee aPnINy visaldueef.ined in M the card profile. Otherwise, the card simulator shall respond with a SW 9000. The L3TSE 3.4 requirement is updated as follows. Get Challenge and Verify The tool is not required to check the CVM List. Always respond as if Enciphered Offline PIN or Plaintext Offline PIN is supported. L3CS 3.4 GimeatgCeh. Iafllteanggisensohtadllerfeinsepdo,ntdheuscianrgdlTataogr isfhparlel suesnet ainnythveacluaer.d M Verify command shall only validate the PIN Value if the PIN is defined in the card profile. Otherwise, the card simulator shall respond with a SW 9000. The Table 4.23 is updated as follows. .CryptoId Attribute .. Tag O 0..1 O 0..1 Default Crypto block if the CryptoId attribute is not present. Zero or one offline PIN value (if supported by the CVM list) - e.g., "1234". © 2026 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. Page 11 .. Tag O 0..1 Z"Ae3roFFo5r 6oCne09U0nDp3rEed9i2c1ta".b(leusNeudmbbyeGr eint hCehxaalldeencgiemcaol mformmaantde).g., The L3CS 5.2 and L3CS 5.4 requirements are replaced by L3CS 3.10 requirements as follows: L3CS 5.2 Offline Enciphered PIN validation. O If supported, the application shall manage PIN try limit and PIN Try counter. L3CS 5.4 Offline Plaintext PIN Validation O L3CS 3.10 PIN Try Limit and PIN Try Counter for Offline PIN validation (Plaintext and M Enciphered). If PIN Try Limit and PIN Try Counter are defined in the card image, the card simulator shall manage the PIN Try Limit and PIN Try Counter as specified in EMV Specifications and shall respond as defined in EMV Specifications. If PIN Try Limit or/and PIN Try Counter are not defined in the card image, the card simulator shall respond as defined in L3CS requirements 1.4 and 3.4. P. Clarification for Card Risk Management The L3CS 5.3 requirement is deleted L3CS 5.3 Card Risk Management function. A terminal test process should not be O interested in internal card logic. Therefore, the CID returned by the Card will be specified in the card image, either with a hardcoded value or using one of the pseudo functions. © 2026 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. Page 12 Q. Clarification for Padding The L3CS 5.5 requirement is now mandatory and becomes L3CS 4.6 (mandatory section). L3CS 5.5 Support of padding (using ‘00’ bytes) in constructed data objects, including in MO file records, as specified in EMV Spec Update No. 69. L3CS 4.6 R. Clarification for Empty record The L3CS 5.6 requirement is now mandatory and becomes L3CS 4.7 (mandatory section). L3CS 5.6 Support for empty file records. MO L3CS 4.7 S. Clarification for Issuer Script Commands The L3TSE 3.8 requirement is deleted L3CS 3.8 Issuer Script Commands (Application Block, Application Unblock, Card M Block, PIN Change, PIN Unblock, Put Data) If the application implements the MAC validation, the appropriate SW defined by the PS shall be returned for an invalid MAC. The L3TSE 5.1 requirement is updated as follows: L3CS 5.1 MAC validation at issuer scripts. O If the application implements the MAC validation, the appropriate SW defined by the PS shall be returned for an invalid MAC. Otherwise, the card simulator shall respond with SW 9000. T. Correction of examples for Table A.33: APDU DataItem Format Some examples in Table A.33: APDU DataItem Format are corrected as below: APDU.80AE.ICC.TAG.77.TAG.9F10 = Issuer Application data in GEN AC response. © 2026 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. Page 13 APDU.80AE.ICC.TAG.77.TAG.9F10.BYTE.0-2 = the 2 first (left most) bytes of the Issuer Application Data APDU.80AE.ICC.TAG.77.TAG.9F10.BYTE.3 = the fourth byte of the Issuer Application Data APDU.80AE.ICC.TAG.77.TAG.9F10.BYTE.3.BIT.0 = the left most bit of the fourth byte of the Issuer Application Data U. Clarification for Table 4.20: TestRun file format The section 4.2 is modified as below: “The machine-readable TSE Test Session files are generated by the L3 TSE Tool. They contain the relevant information for the L3 Test Tool and the tester to perform the selected test cases and checks and then provide the test results, the related logs and tester observations. The order of Check/Step of Check in the below files shall comply with same logical order as present in RuleSet.xml file. The TSE Test Session files are the following XML files archived in a .tse file (a renamed .zip file):” V. Clarification for the display of multiple question with different context The section 4.1.1 Test Set files Considerations is updated as follows: “The file may contain several occurrences of the same context-related data but with a different set of masks. The file is elaborated so that only one context-related data should be in scope at a time. However, it is recommended that test tool vendors exclude any duplicate data. If there are same question/pass criteria with different contexts then the question/pass criteria shall be displayed only once”. For readability, both Mask1 and Mask2 are also present in hexadecimal format: HexMask1 and HexMask2.” The requirement L3TSE 6.1 is updated as bellow: L3TSE 6.1 • L3TSE shall evaluate the Question applicability for each of the M questions to understand whether the question shall be presented to the user. Each Question shall be displayed only once. © 2026 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. Page 14 W. Clarification for the format of SFI and Record Number The table 4.23 : Test Card Image format is updated as bellow: ...P2 Attribute O 0..1 ...sfi Attribute O 0..1 ...record Attribute O 0..1 ...instance Attribute O 0..1 APDU command parameter 2 - e.g., p2="00". Short file identifier in hexadecimal format - e.g., sfi="01". Record number in hexadecimal format - e.g., record="01". Instance number of the terminal request - e.g., instance="1". X. Clarification for the display of Check and Step of Check in UI The L3TSE 17.1 and L3TT 4.8 requirement are updated as follows: L3TSE 17.1 • The selected test cases, on which additionally L3TSE may allow to apply M filters indicated by the Attributes. • The related cards, including the tags defined in the Card File. • The Test Progress as indicated in the TestRun.xml. • The Name, Objective, Configuration, Applicable, Notes, Actions (refer to requirement 17.3 for details) and Requirements. • For a Pass Criteria, the Check number, Step of Check and the Commentary shall be displayed. L3TT 4.8 The L3TT shall be able to display, at minimum, the content of the selected test M cases: • The selected test cases, on which additionally L3TT may allow to apply filters indicated by the Attributes. © 2026 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. Page 15 • The related cards, including the tags defined in the Card File. • The Test Progress as indicated in the TestRun.xml. • The Name, Objective, Configuration, Applicable, Notes, Actions (refer to requirement 4.9 for details) and Requirements. • For a Pass Criteria, the Check number, Step of Check and the Commentary shall be displayed. © 2026 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. Page 16 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, ifat 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 providedsolely by the parties selling or otherwise providing such products or services, and not by EMVCo, andEMVCo 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. © 2026 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. Page 17