SB n°246 Contact - Introduction of Protocol and Parameters Selection

EMV® Specification Bulletin No. 246 First Edition July 2025 Contact – Introduction of Protocol and Parameters Selection This Specification Bulletin changes requirements to improve the data communication speed. Applicability This Specif ication Bulletin applies to: • EMV® Level 1 Specifications for Payment Systems, EMV Contact Interface Specification, Version 1.0, October 2022. Related Documents • General Bulletin No. 48, First Edition, March 2019 - EMV® Contact Specifications - Increased Data Communication Speed • INTERNATIONAL STANDARD, ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols, Third edition, 2006 11-01 Description EMVCo introduces the Protocol and Parameters Selection (PPS) with the changes outlined below f or terminals and cards that operate in negotiable mode with PPS processing. This Specif ication Bulletin ensures interoperability f or the TA1 and PPS1 values in the range '11' to '13', and '18', and in the range '91' to '95' which covers up to 16 times the initial speed with the maximum of 5 MHz clock f requency. This Specif ication Bulletin introduces support f or16 times the initial speed. It incorporates updates related to the publication of the EMV® Contact Interf ace Specif ication, Version 1.0, October 2022 and the addition of TA1 range '91' to '95'. © 2020-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. Page 1 Internal For terminals: Requirements EMV® Contact Interf ace Specif ication, Version 1.0, October 2022 The changes (new requirements) in this bulletin f or terminals choosing to support PPS exchange The changes (new requirements) in this bulletin The changes (new requirements) in this bulletin Date for application New terminal approvals: until end December 2027 New terminal approvals: f rom January 2028 New terminal approvals: f rom January 2031 Approved terminals due f or renewal: f rom January 2033 For cards: Requirements EMV® Contact Interf ace Specif ication, Version 1.0, October 2022 The changes (new requirements) in this bulletin The changes (new requirements) in this bulletin Date for application New card approvals: until end December 2027 New card approvals: f rom January 2028 Approved cards due f or renewal: f rom January 2030 © 2020-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. Page 2 Internal Proposed Specification Changes 4.1 Abbreviations … D Dd Di Dn … f f(max) F Fd Fi Fn … PCB PCK pF POS PPS PPS0 PPS1 to 3 PPSS … S-block SPU Bit Rate Adjustment Factor Bit rate adjustment factor - default value Bit rate adjustment factor - indicated value encoded in TA1 byte of ATR Bit rate adjustment factor - negotiated value after a successful PPS exchange Frequency Maximum frequency supported by the ICC Clock rate conversion factor Clock rate conversion factor - default value Clock rate conversion factor - indicated value encoded in TA1 byte of ATR Clock rate conversion factor - negotiated value after a successful PPS exchange Protocol Control Byte Check character for a PPS exchange Picofarad Point of Service Protocol and Parameters Selection Protocol and Parameters Selection - format byte Protocol and Parameters Selection - parameter bytes Protocol and Parameters Selection - initial byte Supervisory Block Standard or Proprietary Use contact … © 2020-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. Page 3 Internal 6.1.3.2 Warm Reset If the ATR received following a cold reset as described in section 6.1.3.1 does not conform to the specification in section 8 or an unsuccessful PPS exchange requiring warm reset as described in sections 8.6.1 and 8.6.3, the terminal shall initiate a warm reset and obtain an ATR from the ICC as follows (see Figure 7): … Note: Figure 7 indicates that the terminal may initiate the warm reset sequence during the time that the card is still transmitting the cold ATR or PPS response, and in the event that it does, the card shall be able to respond correctly with the warm ATR. … 6.1.3.3 Initiation of Protocol and Parameters Selection (PPS) After completion of a valid ATR (see section 8), the ICC shall wait for characters from the terminal. Their transmission is governed by transmission parameters, F and D, (see section 7.1) and their interpretation is governed by the first offered protocol (see sections 9.2.2 and 9.2.4) and PPS process (see section 8.6). If TA2 is present with b5 = 0 in the ATR, the ICC will operate in specific mode which is governed by the indicated transmission parameters Fi and Di encoded in TA1 and PPS shall not be initiated (see sections 8.3.3.1 and 8.3.3.5). If TA2 is absent in the ATR (negotiable mode), the values of the transmission parameters, F and D, shall continue to apply as follows: • If the value of the first character received by the ICC is 'FF', then the terminal shall have started a PPS exchange (see section 8.6.1); the default values of the transmission parameters, Fd = 372 and Dd = 1, shall continue to apply until completion of a successful PPS exchange (see section 8.6.3), after that the terminal shall start using the negotiated transmission protocol (if applicable) with the negotiated values of the transmission parameters, Fn and Dn. • Otherwise, the terminal shall have started the first offered transmission protocol, T=0 or T=1, in the ATR (see section 8.3) and the default values of the transmission parameters, Fd = 372 and Dd = 1, shall continue to apply. … © 2020-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. Page 4 Internal 7 Physical Transportation of Characters During the transaction process, data is passed bi-directionally between the terminal and the ICC over the I/O line in an asynchronous half duplex manner. A clock signal is provided to the ICC by the terminal, and this shall be used to control the timing of this exchange. The mechanism of exchanging bits and characters is described below. It applies during the answer to reset and a PPS exchange and is also used by both transmission protocols as described in section 9. 7.1 Bit Duration … During the answer to reset and a PPS exchange, the bit duration is known as the initial etu, and is given by the following equation: … Following the answer to reset or a successful PPS exchange (and establishment of the global transmission parameters
F and D, as described in section 8), the bit duration is known as the current etu, and is given by the following equation: … The current etu will start to apply 12 initial etus after the start bit of the last character of the ATR when not performing a PPS exchange, or 12 initial etus after the start bit of the last character of a PPS response when performing a PPS exchange as described in section 8. Note: For the basic answer(s) to reset described in this specification, only values of F = 372 and D = 1 are supported. In the following sections, “etu” indicates current etu unless otherwise specified. … © 2020-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. Page 5 Internal 8 Answer to Reset and Communication Establishment … 8.2 Characters Returned by ICC at Answer to Reset … For proprietary reasons ICCs may optionally support more than one transmission protocol in an ATR, but one of the supported protocols shall be T=0 or T=1. The first offered protocol shall be T=0 or T=1, and the terminal shall continue the card session using the first offered protocol unless for proprietary reasons it supports a mechanism for selecting an alternative protocol offered by the ICC. Support for such a mechanism is not required by, and is beyond the scope of these specifications a PPS exchange is performed as described in section 8.6 after an ATR in negotiable mode. An ICC with an ATR in negotiable mode offering both T=0 and T=1 shall support PPS exchange and either protocol when selected by the terminal (see section 6.1.3.3). Otherwise, such an ICC is not compliant to these specifications. Note: ThisPrevious versions of this specification doesdid not support ICCs having both T=0 and T=1 protocols present in an ATR at the same time. This can only be achieved except by proprietary means beyond the scope of this specification and therefore cards having both T=0 and T=1 protocols present in an ATR may not function properly with legacy terminals. … 8.3.3.1 TA1 TA1 conveys the encoded values of the indicated transmission parameters, FI and DI where: • the m.s. nibble FI(bits b8-b5) is used to determine the value of Fi, the integer representing the indicated value of the clock rate conversion factor, F, and f(max), the maximum value of the frequency supported by the ICC, of the transmission parameters. (See Table 18a for the encoding of bits b8-b5. For the supported values in Table 18a please see the following requirements in this section.) which may be used to modify the frequency of the clock provided by the terminal subsequent to the answer to reset © 2020-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. Page 6 Internal Bits 8 to 5 Fi f (max.) MHz Bits 8 to 5 Fi f (max.) MHz 0000 372 4 1000 RFU - 0001 372 5 1001 512 5 0010 558 6 1010 768 7.5 0011 744 8 1011 1024 10 0100 1116 12 1100 1536 15 0101 1488 16 1101 2048 20 0110 1860 20 1110 RFU — Table 18a: bits b8-b5 of TA1 encoding of Fi and f(max) 0111 RFU — 1111 RFU — • the l.s. nibble DI(bits b4-b1) is used to determine the value of Di, the integer representing the indicated value of the bit rate adjustment factor D, of the transmission parameters (See Table 18b for encoding of bits b4b1. For the supported values in Table 18b please see the following requirements in this section.) which may be used to adjust the bit duration used subsequent to the answer to reset Bits 4 to 1 Di Bits 4 to 1 Di 0000 RFU 1000 12 0001 1 1001 20 0010 2 1010 RFU 0011 4 1011 RFU 0100 8 1100 RFU 0101 16 1101 RFU 0110 32 1110 RFU Table 18b: bits b4-b1 of TA1 encoding of Di See section 7.1 for calculation of the bit duration subsequent to the answer to reset (current etu). Default values of FI = 1372, f(max) = 5 MHz and DI = 1 (also described as Fd and Dd, defining the initial etu duration) indicating values of F = 372 and D = 1, respectively, shall be used during the answer to reset and PPS exchange (see sections 6.1.3 and 8.6). The cold ATR shall contain TA1 as below: • If TA2 is returned with b5 = 0 (specific mode, parameters defined by the interface bytes), TA1 shall be coded with '13' indicating the values of Fi = 372 and Di = 4, respectively. In such case the warm ATR shall be a basic ATR. • If TA2 is not returned (negotiable mode), TA1 shall be coded with a most significant nibble (m.s. nibble) different from 0 and therefore indicate a maximum frequency of at least 5 MHz. TA1 shall be coded with a least significant nibble (l.s. nibble) greater than or equal to 3 and therefore 0111 64 1111 RFU © 2020-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. Page 7 Internal indicating a value of D greater than or equal to 4. In such case the warm ATR shall be a basic ATR. ICCs returning a cold or warm ATR different than explained above are not compliant with this specification. Basic response: The ATR shall not contain TA1 and thus the default values of F and D as Fd = 372 and Dd = 1 shall continue to be used during all subsequent exchanges. Terminal behaviour: If TA1 is present in the ATR (indicated by b5 of T0 set to 1) and TA2 is returned with b5 = 0 (specific mode, parameters defined by the interface bytes), the terminal shall: • Accept the ATR if the value of TA1 is in the range '11' to '13', or '18', or in the range '92' to '95'4 and immediately implement the relevant values of F and D indicated (Fi = 372 or 512 and Di = 1, 2, or 4, 8, 12 or 16). • Reject the ATR if the value of TA1 is not in the range '11' to '13', and not '18', and not in the range '92' to '95' unless it is able to support and immediately implement the conditions indicated.4A If TA1 is present in the ATR (indicated by b5 of T0 set to 1) and TA2 is not returned (negotiable mode), the terminal shall accept the ATR and shall continue as below: • For TA1 not present in the ATR, TA1 = '11', or TA1 = '91' the terminal shall continue using the default values of DF = 1372 and FD = 3721 (also described as Fd and Dd) during all subsequent exchanges, without initiating a PPS request (see section 6.1.3.3) unless the ATR offers both T=0 and T=1 and for proprietary reasons the terminal wishes to select T=1 in which case the PPS exchange is proprietary.4B • For TA1 with the values of '12', '13', or '18', the terminal shall initiate a PPS request with PPS1 = TA1 (see section 8.6) • For TA1 = '14', the terminal shall initiate a PPS request with PPS1 = '13' unless it supports the proprietary parameters requested by TA1 and is able to initiate a PPS request for the value accordingly (see section 8.6)4A • For TA1 in the range '92' to '95', the terminal shall initiate a PPS request with PPS1 = TA1 (see section 8.6) • For TA1 = '98', the terminal shall initiate a PPS request with PPS1 = '94' unless it supports the proprietary parameters requested by TA1 and is able to initiate a PPS request for the value accordingly (see section 8.6)4A © 2020-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. Page 8 Internal • For TA1 with the values of '96', '97', or '99', the terminal shall initiate a PPS request with PPS1 = '95' unless it supports the proprietary parameters requested by TA1 and is able to initiate a PPS request for the value accordingly (see section 8.6)4A • For TA1 not in the range '11' to '14', and not '18', and not in the range '91' to '99', the terminal shall continue as below, unless it supports proprietary handling for the parameters requested by TA1 and is able to initiate a proprietary PPS request accordingly (see section 8.6)4A: ▪ initiate a PPS request with: o PPS1 = '18' if the m.s. nibble (bits b8-b5) in TA1 = 1 o PPS1 = '13' if the m.s. nibble (bits b8-b5) in TA1 > 1 and l.s. nibble (bits b4-b1) > 2 ▪ reject ATR if the m.s. nibble (bits b8-b5) in TA1 = 0 or l.s. nibble (bits b4-b1) < 3 unless it supports a proprietary technique for negotiating the parameters to be used. If TA1 is absent from the ATR, the default values of F and D as = 1 and Fd = 372 and Dd = 1 shall be used during all subsequent exchanges. 4 Terminals compliant to version 3.1.1 of the EMV Specifications may reject an ATR (not an ICC) if TA1 is present and coded other than '11'. ATRs indicating the higher allowable values of D will include TA1 coded '12', or '13', and thus may be rejected in 3.1.1 compliant terminals. Therefore, to ensure that an ICC with an ATR indicating a TA1 value different from '11' supporting higher data transfer rates is always accepted in 3.1.1 compliant terminals (albeit operating at basic data transfer rates), it is essential that any TA1 indicating higher data rates different from '11' is present in the cold ATR only, and that a basic warm ATR is always presentwhich either does not contain TA1, or includes a TA1 having the value '11'. 4A Communication interoperability is not guaranteed by this version of the specification for terminals supporting TA1 values that are not in the range '11' to '13', and not '18', and not in the range '92' to '95'. 4B Interoperability of the proprietary PPS exchange and further communication is not guaranteed by this specification. Although this PPS exchange may be proprietary it is recommended to be as described in section 8.6. Legacy cards may not function properly with a PPS exchange based on section 8.6. … © 2020-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. Page 9 Internal 8.3.3.3 TC1 TC1 conveys the value of N, where N is used to indicate the extra guardtime that shall be added to the minimum duration between the leading edges of the start bits of two consecutive characters for subsequent exchanges from the terminal to the ICC. N is binary coded over bits b1–b8 of TC1, and its value represents the number of etus to be added as extra guardtime. TC1='FF' has a special meaning and indicates that the minimum delay between the leading edges of the start bits of two consecutive characters shall be reduced to 12 etus during a PPS request, 12 etus if T=0 is to be used, or 11 etus if T=1 is to be used. Note: TC1 applies only to the timing between two consecutive characters sent from the terminal to the ICC. It does not apply to the timing between consecutive characters sent from the ICC to the terminal, nor does it apply to the timing between two characters sent in opposite directions (see sections 8.6.1, 9.2.2.1 and 9.2.4.2.2) except when an ICC is expected to be able to receive a PPS request as described in section 8.6.1. N may take any value between 0 and 255. If the value of TC1 is in the range '00' to 'FE', between 0 and 254 etus of extra guardtime shall be added to the minimum character to character duration, which for subsequent transmissions shall be between 12 and 266 etus. If the value of TC1 = 'FF', then the minimum character to character duration for subsequent transmissions shall be 12 etus during a PPS request, 12 etus if T=0 is to be used, or 11 etus if T=1 is to be used. … 8.4 Terminal Behaviour during Answer to Reset … • If the terminal detects a parity error in a character returned in the ATR, it shall initiate the deactivation sequence within 24,000 initial etus (19,200 + 4,800 initial etus) measured from the leading edge of the start bit of the TS character of the ATR. • Upon receipt of ▪ a valid cold or warm reset ATR not in negotiable mode complying with the timings described above, the terminal shall proceed with the card session using the returned parameters. ▪ a cold or warm ATR in negotiable mode complying with the timings described above, the terminal shall proceed with the card session o using default values of F and D parameters (see section 8.3.3.1 for the conditions in which the terminal is allowed to continue with default parameters without sending PPS request), or o by sending a PPS request using default values of F and D parameters during the PPS exchange, or o in the case of a cold ATR initiate a warm reset (see section 6.1.3.2). © 2020-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. Page 10 Internal • It may continue the card session as soon as the last character of the valid ATR (as indicated by the bit map characters T0 and/or TDi) and TCK, if present, has been received. • In the case of a PPS request not being initiated, Bbefore transmitting the first character to continue the card session, it shall wait at least the guardtime applicable to the protocol to be used (16 etus for T=0, BGT for T=1) measured from the leading edge of the start bit of the last character of the valid ATR. • In the case of a PPS request being initiated see section 8.6.1. for the requirements. © 2020-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. Page 11 Internal 8.5 Answer to Reset - Flow at the Terminal … START Set Case = 1 (See Note 1) Cold Reset Note 1: ‘Case’ is a process variable used to indicate whether a cold or warm reset is operative. Case = 1 for a cold reset, and Case = 2 for a warm reset. Note 2: If the process aborts at this point, the ICC may be acceptable in this terminal by business agreement. The terminal should be primed to accept the ICC prior to insertion. Any subsequent processing is proprietary and beyond the scope of this specification. Note 3: If the process aborts at this point, reset may be retried after removing the ICC from the terminal and taking corrective action as required. An appropriate message should be displayed on the terminal. Note 4: A proprietary card session beyond the scope of this specification may be started at this point e.g. initiating a PPS request for parameters beyond the EMV specified values. Warm Reset Set Case = 2 Is ATR check 1 Yes OK? ATR check 1 is OK if parity and TCK (if returned) are correct, and the No tim ings specified in section 8.4 are respected ABORT (See Note 3) Is ATR check 2 No OK? ATR check 2 is OK if the parameters and structure of the ATR conform to the requirements of section 8 Yes OR if a proprietary ATR is recognised Continue using param eters determined above or initiate a PPS request for an ATR in negotiable mode OR (See Note 4) Yes Is Case = 1? No ABORT (See Note 2) © 2020-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. Page 12 Internal 8.6 Protocol and Parameters Selection (PPS) This section explains the Protocol Parameter Selection (PPS) process. PPS allows terminals to adjust D and F values (up to the values encoded in TA1 of an ATR) and select a protocol offered by the card. This specification does not support terminals selecting a protocol beyond T=0 and T=1. For ATRs offering both protocols (T=0 and T=1) in the same ATR, the terminal shall select the T=1 protocol in preference to T=0 (see section 9). Note: Previous versions of this specification did not support PPS except as a proprietary mechanism and therefore legacy ICCs may not function properly with a PPS exchange as described in this section. 8.6.1 Physical Transportation of Characters during PPS Exchange This section describes the structure and timing of the PPS exchange and characters used during PPS. The PPS exchange shall start as specified in 6.1.3.3. The bit duration is defined in section 7.1, and the character frame is defined in section 7.2, using the logic convention fixed by TS (see section 8.3.1). During the PPS exchange, the minimum interval between the leading edges of the start bits of two consecutive characters sent by the terminal shall be as indicated in TC1 of the ATR (see section 8.3.3.3), and by the ICC shall be 12 initial etus. The ICC shall be able to correctly interpret characters sent by the terminal with a minimum interval between the leading edges of the start bits of two consecutive characters of 11.8 + N etus where N is retuned in TC1 (if TC1='FF' then N shall be taken as 0). The terminal shall be able to correctly interpret characters sent by the ICC with a minimum interval between the leading edge of the start bit of any character sent by the ICC and the leading edge of the previous character sent either by the ICC or the terminal of 11.8 etus. The minimum interval between the leading edge of the start bit of the first character sent by the ICC and the leading edge of the start bit of the previous character sent by the terminal shall be 12 etu. The minimum interval between the leading edge of the start bit of the last character of the ATR sent by the ICC and the first character of the PPS request sent by the terminal shall be 22 initial etus. © 2020-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. Page 13 Internal The ICC shall be able to correctly interpret a PPS request with a minimum interval between the leading edge of the start bit of the last character of the ATR sent by the ICC and the first character of the PPS request sent by the terminal of 11.8 + N etus where N is retuned in TC1 (if TC1='FF' then N shall be taken as 0). The maximum interval between the leading edge of the start bit of the first character sent by the ICC and the leading edge of the start bit of the previous character sent by the terminal shall be 48 initial etus. The maximum interval between the leading edges of the start bits of two consecutive characters sent by the terminal shall be 13 + N initial etus where N is returned in TC1 (if TC1='FF' then N shall be taken as 0). The maximum interval between the leading edges of the start bits of two consecutive characters sent by the ICC shall be 13 initial etus. The ICC shall correctly interpret a PPS request with the maximum interval between the leading edges of the start bits of two consecutive characters sent by the terminal up to • 480 initial etus for an ICC returning an ATR offering T=0 • CWT+4 initial etus for an ICC returning an ATR offering T=1 only. The terminal shall correctly interpret a PPS response with the maximum interval between the leading edge of the start bit of any character sent by the ICC and the leading edge of the start bit of the previous character sent either by the ICC or the terminal up to 10,080 (9,600 + 480) initial etus. If a character is not received within this time, the terminal shall: • initiate a warm reset (see section 6.1.3.2) in the case of a PPS exchange following a cold reset4C • abort the card session by initiating the deactivation sequence in the case of a PPS exchange following a warm reset within 14,400 initial etus (9,600 + 4,800 initial etus) following the leading edge of the start bit of the last character (the character from which timeout occurred). The ICC and the terminal shall correctly interpret all the characters received during a PPS request and a PPS response respectively, provided they are received within 19,200 initial etus. This time is measured between the leading edge of the start bit of PPSS and 12 initial etus after the leading edge of the start bit of the last character. If a PPS response from the ICC is not completed within 19,200 initial etus the terminal shall: • initiate a warm reset (see section 6.1.3.2) in the case of a PPS exchange following a cold reset4C • abort the card session by initiating the deactivation sequence in the case of a PPS exchange following a warm reset within 24,000 initial etus (19,200 + 4,800 initial etus) measured from the leading edge of the start bit of the PPSS character. © 2020-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. Page 14 Internal During a PPS exchange following an ATR offering T=0, the receiver and transmitter shall implement error detection and correction as described in section 9.2.3. If the ATR does not offer T=0 the error indication and character repetition explained in section 9.2.3 shall not be implemented. 4C Performing a warm reset following a failed PPS exchange is not described in ISO/IEC 7816-3 however it ensures interoperability with legacy EMV cards which may not implement PPS exchange in accordance with this specification. 8.6.2 PPS Request and Response If the ATR is in negotiable mode with TA1 present and other than '11' the terminal shall transmit a PPS request to the ICC. If the ATR is in negotiable mode with TA1 not present or TA1 = '11' and offering both T=0 and T=1 the terminal may transmit a PPS request to the ICC if it wishes to select T=1 for proprietary reasons in which case the PPS exchange is proprietary.4D If an ICC with an ATR in negotiable mode with TA1 present and other than '11' receives a valid PPS request (as defined in section 8.6.3 below), it shall transmit a PPS response. The PPS request and PPS response each consist of an initial byte PPSS, followed by a format byte PPS0, three optional parameter bytes PPS1, PPS2, PPS3 and a check byte PCK as the last byte. • PPSS identifies the PPS request or response and is set to 'FF'. • In PPS0, each bit b5, b6 or b7 set to 1 indicates the presence of the bytes PPS1, PPS2, PPS3, respectively. Bits b4-b1 encode a protocol type T to propose a transmission protocol. Bit b8 is RFU (set to 0). The coding of PPS0 in the PPS request shall be as shown in Table 24a, unless the terminal supports the proprietary parameter indicated in the ATR and is able to initiate the PPS request for the values accordingly.4E For an ATR with TA1 present and different from '11' and offering both T=0 and T=1 the terminal shall request T=1 in PPS0. © 2020-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. Page 15 Internal b8 b7 b6 b5 b4 b3 b2 b1 For ATRs offering T=0 but not T=1 0 0 0 1 0 0 0 0 For ATRs offering T=1 with or without offering 0 0 0 1 0 0 0 1 T=0 Table 24a: Coding of Character PPS0 • PPS1 allows the terminal to propose values of F and D to the ICC. Encoded in the same way as in TA1, these values shall be from Fd to Fi and from Dd to Di, respectively. ▪ The terminal shall always transmit PPS1 (see section 8.3.3.1 for coding of PPS1 for terminals). ▪ For PPS1 values: o in the range '11' to '13' that are within the range from Fd to Fi and from Dd to Di, or PPS1 of '18' (only if m.s. nibble (bits b8-b5) in TA1 = 1 and TA1 not in the range '11' to '14') or o in the range '91' to '95' that are within the range from Fd to Fi and from Dd to Di, the ICC shall always transmit PPS1 in the PPS response. The ICC shall acknowledge the values in PPS1 of the PPS request by sending the same PPS1 in the PPS response. For other values of PPS1 the PPS exchange is proprietary and the behaviour of the ICC is not defined by this specification.4E ▪ If the ICC sent m.s. nibble in the TA1 byte of its ATR > 1 it shall acknowledge and be able to support a PPS request containing PPS1 = '13'. • PPS2 allows the terminal to propose a use of SPU. The terminal shall not transmit PPS2 unless it supports a proprietary parameter in the ATR and is able to support PPS2 values accordingly.4F • PPS3 is reserved for future use. The terminal shall not transmit PPS3. • Exclusive-ORing all the bytes PPSS to PCK inclusive shall give '00'. Any other value is invalid. 4D Interoperability of the proprietary PPS exchange and further communication is not guaranteed by this specification. Although this PPS exchange may be proprietary it is recommended to be as described in section 8.6. Legacy cards may not function properly with a PPS exchange based on section 8.6. © 2020-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. Page 16 Internal 4E The result of the proprietary PPS exchange and further communication interoperability with PPS0 values other than in Table 24a and PPS1 values not in the range '11' to '13', not '18', and not in the range '91' to '95' is not guaranteed by this version of the specification. 4F The result of the proprietary PPS exchange using PPS2 and further communication interoperability are not guaranteed by this version of the specification. 8.6.3 Successful and Unsuccessful PPS Exchange A PPS request shall be considered valid by the ICC if all the following conditions are satisfied: • The value of b7-b5 of PPS0 is consistent with the characters PPS1 to PPS3 included in the request • The value of b4-b1 of PPS0 is consistent with the protocols offered by the ICC in the ATR • PPS1 is present, has a value in the range '11' to '13', or '18', or in the range '91' to '95' and the F and D values encoded in the PPS1 are in the range from Fd to Fi and from Dd to Di respectively. • PPS2 is not present. • Exclusive-ORing all the bytes PPSS to PCK inclusive is '00' A PPS request shall be considered invalid by the ICC if any of the following conditions are satisfied: • The value of b7-b5 of PPS0 is inconsistent with the characters PPS1 to PPS3 included in the request • Exclusive-ORing all the bytes PPSS to PCK inclusive is not '00' If the ICC receives an invalid PPS request it shall not transmit any response. If a PPS request is neither valid or invalid as defined above, then the PPS exchange is proprietary and the behaviour of the ICC is not defined by this specification. 4E A PPS response shall be considered invalid by the terminal if: • The value of PPSS is not 'FF' • The value of b7-b5 of PPS0 is inconsistent with the characters PPS1 to PPS3 included in the response • For PPS1 values in the PPS request: ▪ in the range '11' to '13' that are within the range from Fd to Fi and from Dd to Di, or '18' (only if m.s. nibble (bits b8-b5) in TA1 = 1 and TA1 not in the range '11' to '14') or ▪ in the range '91' to '95' that are within the range from Fd to Fi and from Dd to Di, the values of PPS0 and PPS1 in the PPS response are not identical to PPS0 and PPS1 in the PPS request. For other PPS1 values in the PPS request the PPS exchange (both request and response) is proprietary and the behaviour of the terminal is not defined by this specification4E © 2020-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. Page 17 Internal • Exclusive-ORing all the bytes PPSS to PCK inclusive is not '00' If the terminal receives an invalid response it shall: • initiate a warm reset (see section 6.1.3.2) in the case of a PPS exchange following a cold reset4C • initiate a deactivation sequence in the case of a PPS exchange following a warm reset within 24,000 initial etus (19,200 + 4,800 initial etus) measured from the leading edge of the start bit of the PPSS character. Otherwise, the PPS response is considered valid and the PPS exchange has been completed successfully. The F and D values encoded in the PPS request and response become Fn and Dn to be used in the session. The terminal shall wait at least the guardtime applicable to the negotiated protocol to be used (16 etus for T=0, BGT for T=1) measured from the leading edge of the start bit of the last character of the PPS response and the first character to continue the card session with the negotiated parameters. The ICC shall continue the session with the negotiated parameters. … © 2020-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. Page 18 Internal 9 Transmission Protocols This section defines the structure and processing of commands initiated by the terminal for transmission control and for specific control in asynchronous half duplex transmission protocols. Two types of protocol are defined, character protocol (T=0) and block protocol (T=1). ICCs shall support either protocol T=0 or protocol T=1. Terminals shall support both protocol T=0 and T=1. The protocol to be used for subsequent communication between the ICC and terminal is indicated in TD1, and shall be T=0 or T=1. If TD1 is absent in the ATR, T=0 is assumed. The protocol indicated by the ICC applies immediately after the answer to reset, as there is no PTS procedure when no PPS exchange is performed or immediately after the PPS exchange when performed as described in section 8.6. Other parameters returned in the ATR and relevant to a specific protocol are defined in sections 9.2 through 9.4. … 9.2.4.2.2 Timing for T=1 … Note: In general, for values of FI other than 372 and DI other than 1, BWT is calculated using the formula: … © 2020-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. Page 19 Internal Legal Notice The EMV® Specif ications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability f or any errors or omissions contained in these Specif ications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUD ING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specif ications. EMVCo undertakes no responsibility to determine whe ther any implementation of the EMV® Specif ications may violate, inf ringe, 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 the EMV® Specif ications should consult an intellectual property attorney bef ore any such implementation. Without limiting the f oregoing, the Specif ications may provide f or 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 these Specif ications is solely respons ible f or determining whether its activities require a license to any such technology, including f or patents on public key encryption technology. EMVCo shall not be liable under any theory f or any party’s inf ringement of any intellectual property rights in connection with the EMV® Specif ications © 2020-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. Page 20 Internal