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

EMV® Level 3 Technical Bulletin No. 321 First Edition, March 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 ............................................................ 7 L. Correction of and tags occurrence in Selected.xml ........................................ 8 M. Correction and clarification for emvcard.sdad() pseudo-function description ............................... 9 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 . or .. ..AID ..cryptoId ..PartialMatchLength ... Block/Tag/Attribute Block-start Block-start Attribute Attribute Attribute Block-start M/O/C Occurrence O 0..2 O 0..n M 1..1 O 0..1 O 0..1 M 1..n Description and Requirement 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. An application is made of one or more terminal request(s). 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. 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. Optional attribute used for Partial AID Selection. If not present, refer to L3CS 1.10 requirement. 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 and one NETWORK log shall be attached to a test case. These logs can contain multiple transactions. © 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 provides 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 summarizes the requirements for L3TSEFIGVersion and L3TTFIGVersion depending on Mode in TestRunInfo.xml. Step 1 Mode in TestRunInfo.xml Mode_Question 2 Mode_Info 3 Mode_TestResult (all test cases are not tested) 4 Mode_Regression (all test cases are not tested) 5 Mode_TestResult (some test cases have been executed) L3TSEFIGVersion presence Mandatory Mandatory Mandatory Mandatory Mandatory Comments If L3TSE updates the file, L3TSEFIGVersion must be updated by the version of the tool. If L3TSE updates the file, L3TSEFIGVersion must be updated by the version of the tool. If L3TSE updates the file, L3TSEFIGVersion must be updated by the version of the tool. L3TSEFIGVersion must be updated by the version of the tool because one question with regression mode has been updated. No change required. L3TTFIGVersion Presence Empty or Tag Not present Empty or Tag Not present Can be present Can be present Mandatory Comments Not applicable Not applicable If L3TTFIGVersion is present, it must not be removed, and it can be updated by the version of the tool. If L3TTFIGVersion is present, it must not be removed, and it can be updated by the version of the tool. L3TTFIGVersion must be updated by the version of the tool. Context TestRunInfo.xml created by L3 TSE TestRunInfo.xml created by L3 TSE TestRunInfo.xml created by L3 TSE File updated by L3 TSE 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 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 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 ... .... .... .... ....DA Block/Tag/Attribute Block-start Tag Tag Tag Attribute M/O/C O M Occurrence 0..n 1..1 O 0..1 M 1..1 C O 0..1 Description and Requirement Zero or more Command Response blocks. Either a command APDU or an event literal – e.g., "EVENT_POWER_ON". 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 initialized 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. 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. 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. © 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 Field .... ... Block/Tag/Attribute Tag Block-end M/O/C Occurrence O 0..1 Description and Requirement 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. L. Correction of and tags occurrence in Selected.xml Table 4.21 is updated as follows Table 4.21: Selected file Format Field file_version originator updatedby . .. ... Block/Tag/Attribute Tag Block-start Attribute Attribute Attribute Block-start Block-start Tag M/O/C M Occurrence 1..1 M 1..1 M 1..1 M 1..1 O 0..1 M 1..n => 1..1 M 1..1 => 1..n M 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 8 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 authorizations 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 9 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 10