PCI Watch

Tracking changes across the Payment Card Industry

SB n° 332: Contact Clarification for Terminal Requirements for TA1=91 in Negotiable Mode

Specification Bulletins
ChipContact Acceptance DeviceCard

© 202 0-2026

countries.

Internal EMV® Specification Bulletin No. 332 First Edition August 2026 Contact – Clarification for Terminal Requirements for TA1 = 91 in Negotiable Mode This Specification Bulletin changes requirements to improve the data communication speed.

Applicability

This Specification Bulletin applies to:

  • EMV® Specification Bulletin No. 246, First Edition July 2025, Contact – Introduction of Protocol and Parameters Selection [1]

Related Documents

  • EMV® Level 1 Specifications for Payment Systems, EMV Contact Interface Specification, Version 1.0, October 2022.
  • General Bulletin No. 48, First Edition, March 2019 - EMV® Contact Specifications - Increased Data Communication Speed Effective Date and Approval Readiness Date
  • For both cards and terminals immediately applicable to document [1]. For details, please refer to “Date for application” tables in document [1].

Description

The proposed changes to SB246 [1] provide interoperability enhancement for the Protocol and Parameters Selection (PPS) process in negotiable mode, specifically addressing a scenario where ATR returns TA1 = '91' in negotiable mode and resolves the conflict among the requirements. This SB ensures interoperability for the TA1 = '91' value in ATR when returned in negotiable mode permitting terminal to proceed with the transaction at the default speed. Proposed Specification Change Change in section 8.6.2 as follows:

8.6.2 PPS Request and Response If the ATR is in negotiable mode with TA1 present and other than '11' and '91', the terminal shall transmit a PPS request to the ICC. If the ATR is in © 2020- 2026

countries.

Internal negotiable mode with TA1 not present or TA1 = '11' or '91', 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' and ' 91' 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 PPS 1, PPS2, PPS 3 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 b 5, b6 or b 7 set to 1 indicates the presence of the bytes PPS 1, PPS2, PPS3, respectively. Bits b 4-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 ' 91' and offering both T=0 and T=1 the terminal shall request T=1 in PPS0. … © 2020- 2026 countries. Internal

Legal Notice

The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. 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 THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications 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 the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications 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 these Specifications 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 the EMV® Specifications