SB nº 247: Contact – Communication Performance Enhancement

v2.0 Specification Bulletins
Contact Acceptance DeviceCard

EMV<sup>®</sup> Specification Bulletin No. 247 Second Edition, July 2021 Contact – Communication Performance Enhancement This Specification Bulletin changes requirements to improve the data communication speed

Applicability

This Specification Bulletin applies to:

  • EMV Integrated Circuit Card Specifications for Payment Systems, Book 1 - Application Independent ICC to Terminal Interface Requirements, Version 4.3, November 2011.

Related Documents

  • General Bulletin No. 48, First Edition, March 2019 - EMV Contact Specifications - Increased Data Communication Speed
  • EMV Specification Bulletin No. 247, First Edition, January 2021
  • Specification Bulletin No. 218, Second Edition April 2020 - Contact – ATR parameter requirements
  • INTERNATIONAL STANDARD, ISO/IEC 7816-3, Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols, Third edition, 200611-01

Description

This second edition of the bulletin clarifies the limitation of the maximum intervals between the characters sent by ICC. It clarifies that characters repeated due to the indication of a parity error are excluded from this limitation. To reduce transaction time in addition to General Bulletin No. 48 and SB218, EMVCo will enforce the changes outlined below.

countries.

For terminals: Requirements The changes (new requirements) in this bulletin EMV Book 1 version 4.3 The changes (new requirements) in this bulletin Date for application Approved terminals due for renewal: from January 2026 New terminal approvals: until end December 2021 New terminal approvals: from January 2022 For cards: Requirements The changes (new requirements) in this bulletin EMV Book 1 version 4.3 The changes (new requirements) in this bulletin Date for application Approved cards due for renewal: from January 2023 New card approvals: until end December 2021 New card approvals: from January 2022 Proposed Specification Changes 8.1 Physical Transportation of Characters Returned at Answer to Reset This section describes the structure and timing of the characters returned at the answer to reset. The bit duration is defined in section 7.1, and the character frame is defined in section 7.2. During the answer to reset, the minimum interval between the leading edges of the start bits of two consecutive characters shall be 12 initial etus, and the maximum interval between the leading edges of the start bits of two consecutive characters shall be 9600480 initial etus. The ICC shall transmit all the characters to be returned during an answer to reset (warm or cold) within 19,200960 initial etus.4 This time is measured between the leading edge of the start bit of the first character (TS) and 12 initial etus after the leading edge of the start bit of the last character. …

countries.

8.3.3.7 TC2 TC2 is specific to protocol type T=0 and conveys the work waiting time integer (WI) that is used to determine 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 (the work waiting time). The work waiting time is given by 960 x D x WI. See section 9.2.2.1 for additional requirements that are imposed for maximum interval limitations related to the work waiting time and inter-character timing during transmission. … 9.2.2.1 Specific Options - Character Timing for T=0 The minimum interval between the leading edges of the start bits of two consecutive characters sent by the terminal to the ICC shall be between 12 and 266 etus as determined by the value of TC1 returned at the answer to reset (see sections 8.2 and 8.3). This interval may be less than the minimum interval of 16 etus allowed between two characters sent in opposite directions. If the value returned in TC1 is N (if TC1=’FF’ then N shall be taken as 0), 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. The minimum interval between the leading edges of the start bits of two consecutive characters sent by the ICC to the terminal shall be 12 etus. The terminal shall be able to correctly interpret characters sent by the ICC with a minimum interval between the leading edges of the start bits of two consecutive characters of 11.8 etus. The maximum interval between the leading edges of the start bits of any two consecutive characters sent by the terminal shall not exceed 13 + N etus where N is the value 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 any two consecutive characters sent by the ICC, other than a '60' procedure byte previously sent by the ICC and characters repeated due to the indication of a parity error, shall not exceed 13 etus. 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 or the previous '60' procedure byte sent by the ICC (the Work Waiting Time, or WWT) shall not exceed 960 x D x WI etus (D and WI are returned in TA1 and TC2, respectively).

countries.

… 9.2.4.2.2 Timing for T=1 The minimum interval between the leading edges of the start bits of two consecutive characters sent by the terminal to the ICC shall be between 11 and 42 etus as indicated by the value of TC1 returned at the answer to reset (see sections 8.2 and 8.3). If the value returned in TC1 is N (if TC1=’FF’ then N shall be taken as -1), 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. … 9.2.4.3 Error Free Operation … 3. If the ICC wishes The ICC shall not send an S(IFS request) block to change the size of the IFSC to change the size of the IFSC from the initial value indicated at the answer to reset. The terminal, it shall sendsupport a S(IFS request) block sent by a card that wishes to change the size of the IFSCto the terminal. The PCB of the S(IFS request) block shall havehas the value 'C1' indicating a request to change the IFSC. The INF field shall contain a byte the value of which indicates the size in bytes of the requested new IFSC. This byte shall have a value in the range '10' to 'FE'. The terminal shall support an INF byte in the range '10' to 'FE' and return a S(IFS response) block to the ICC acknowledging the change to the size of the IFSC. The PCB of the S(IFS response) block sent in response shall have the value 'E1', and the INF field shall have the same value as the INF field of the block requesting the change. …

countries.

Legal Notice

The EMV<sup>®</sup> 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<sup>®</sup> 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<sup>®</sup> 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<sup>®</sup> Specifications

countries.