PCI Watch

Tracking changes across the Payment Card Industry

SB nº 218: Contact ATR Parameter Requirements

v2.0 Specification Bulletins
Contact Acceptance DeviceCard

EMV<sup>®</sup> Specification Bulletin No. 218 Second Edition April 2020 Contact – ATR parameter requirements This Specification Bulletin changes the ATR parameters to improve the data communication speed in relation to General Bulletin No. 48

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
  • Specification Bulletin No. 216, Third Edition, March 2020, Contact – Terminology removal for Vpp
  • 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 Effective Date and Approval Readiness Date
  • See "Date for application" tables in Specification Changes below.

Description

To reduce transaction time as relevant to General Bulletin No. 48, EMVCo will enforce the changes outlined below, to ensure that maximum data communication speed is guaranteed in all transactions when the card operates in specific mode, and potentially terminals that support PPS (Protocol and Parameters Selection) when the card operates in negotiable mode. This second edition aligns the Effective Date and Approval Readiness Date for cards with testing availability.

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 September 2021 New card approvals: until end December 2020 New card approvals: from January 2021 Cards shall implement either:

  • A cold ATR with TA1 in specific mode 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 F = 372 and D = 4, respectively. In such case the warm ATR shall be a basic ATR. or:
  • A cold ATR with TA1 in negotiable mode as below: 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 indicating a value of D greater than or equal to 4. In such case the warm ATR shall be a basic ATR. The Basic response ATR parameters are modified as indicated below (if present):
  • TC1= ‘00’ or ‘FF’
  • TA3 = ‘7C’ to ‘FE’
  • TB3 least significant nibble (l.s. nibble) 0 to 1 It is also recommended that cards support optimised protocol parameters that minimise delays on communication e.g. supporting T=1 only, applying only minimum extra guard time, optimum character waiting times and block waiting times where applicable. In this respect, the values below are recommended for ATRs that are not basic: TC1=’FF’ (for T=1), TD1=’x1’, TB3=’x0’ (for T=1) countries. Specification Changes Amend sections and tables as follows:

5.3.6 Supply Voltage (VCC) … For proprietary reasons terminals may support the capability to negotiate with the ICC the voltage class to be used, but this is outside the scope of EMV, and there is no requirement for ICCs conforming to this specification to support such negotiation. If the ICC returns a class indicator in the ATR as defined in ISO/IEC 7816-3, the ATR may be rejected in an EMV compliant terminal. To avoid interoperability problems, any class indicator used should be returned in the cold ATR; to guarantee that the ICC will be accepted in the event that the cold ATR is rejected, until end December 2020 the warm ATR should be one of the basic ATRs defined in section 8. From January 2021, the warm ATR shall be basic. … 8.2 Characters Returned by ICC at Answer to Reset … Note: This specification does not support ICCs having both T=0 and T=1 protocols present at the same time. This can only be achieved by proprietary means beyond the scope of this specification. Note: It is strongly recommended that T=1 protocol should be used for optimum performance and since T=0 protocol may not be supported in future versions of this specification. Also for proprietary reasons ICCs may optionally support other values of the transmission control parameters at the issuer’s discretion. However, such support is considered outside the scope of this specification and such ICCs may be rejected at terminals conforming to this specification, which need not have the corresponding additional proprietary functionality required to support the ICC. The characters returned by the ICC at the answer to reset for the two basic answers to reset are shown in Table 15 and Table 16. The characters are shown in the order in which they are sent by the ICC, that is, TS first.

countries.

If protocol type T=0 only is supported (character-oriented asynchronous transmission protocol), the characters returned shall be as shown in Table 15: Character TS T0 Value '3B' or '3F' '6x' for a cold ATR '6x' or '4x' for a warm ATR TB1 '00' TC1 Until end December 2020: '00' to 'FF' From January 2021: '00' or 'FF' Remarks Indicates direct or inverse convention TB1 and TC1 present; x indicates the number of historical bytes present TB1 optionally present and TC1 present; x indicates the number of historical bytes present VPP not requiredThe presence of TB1 has been deprecated by ISO/IEC 78163:2006, however the value '00' is kept here for backwards compatibility with existing terminals and its presence is mandatory for a basic cold ATR but is optional for a basic warm ATR. Indicates the amount of extra guardtime required. Value 'FF' has a special meaning (see section 8.3.3.3) Table 15: Basic ATR for T=0 Only If protocol type T=1 only is supported (block-oriented asynchronous transmission protocol), the characters returned shall be as shown in Table 16: Character TS T0 Value '3B' or '3F' 'Ex' for a cold ATR 'Ex' or 'Cx' for a warm ATR Remarks Indicates direct or inverse convention TB1 to TD1 present; x indicates the number of historical bytes present TB1 optionally present and TC1, TD1 present; x indicates the number of historical bytes present

countries.

TB1 TC1 TD1 TD2 TA3 TB3 TCK '00' Until end December 2020: '00' to 'FF' From January 2021: '00' or 'FF' '81' '31' Until end December 2020: '10' to 'FE' From January 2021: '7C' to 'FE' m.s. nibble '0' to '4' Until end December 2020: l.s. nibble '0' to '5' From January 2021: l.s. nibble '0' or '1' See section 8.3.4 VPP not requiredThe presence of TB1 has been deprecated by ISO/IEC 78163:2006, however the value '00' is kept here for backwards compatibility with existing terminals and its presence is mandatory for a basic cold ATR but is optional for a basic warm ATR. Indicates amount of extra guardtime required. Value 'FF' has special meaning (see section 8.3.3.3) TA2, TB2, and TC2 absent; TD2 present; T=1 to be used TA3 and TB3 present; TC3 and TD3 absent; T=1 to be used Returns IFSI, which indicates initial value for information field size for the ICC and IFSC of: Until end December 2020: 16–254 bytes From January 2021: 124–254 bytes BWI = 0 to 4 Until end December 2020: CWI = 0 to 5 From January 2021: CWI = 0 or 1 Check character Table 16: Basic ATR for T=1 Only

countries.

8.3 Character

Definitions

This section provides detailed descriptions of the characters that may be returned at the answer to reset. Each character description includes the following information:

  • title
  • explanation of usage as described in ISO/IEC 7816-3
  • basic response (Until end December 2020, Tthis response should always be used in a warm ATR to ensure interoperability. From January 2021, this response shall always be used in a warm ATR.)
  • required terminal behaviour in the event that a terminal receives characters outside the range allowed by EMV The ‘basic response’ indicates the presence or absence of the character, and the allowable range of values it may take (if present) if it is to conform to one of the basic ATRs. The description of a basic response (even though indicated by ‘shall’) is not intended to preclude the use of other values of the characters, nor the omission/inclusion of a character at the issuer’s discretion. For example, the ICC may return additional characters if it supports more than one transmission protocol (see section 9). However, only ICCs returning a basic ATR, or an ATR supported by the minimum required terminal functionality described below, are guaranteed to be supported correctly in interchange. From January 2021, the warm ATR shall always be basic. Terminals conforming to this specification are only required (as a minimum) to support the basic ATRs described here together with anythe additional requirements specified in ‘terminal behaviour’. Terminals may thus reject an ATR containing interface bytes not described in, or having values not specified in, this specification. However, terminals may correctly interpret such an ATR if it is returned by an ICC for proprietary (for example, national) use. Such terminal functionality is not mandatory and is beyond the scope of this specification. As a general principle, a terminal should accept a non-basic ATR if it is able to function correctly with it. Terminals shall be capable of checking the parity of characters returned in the answer to reset, but not necessarily as they are received. If the terminal detects a parity error, it shall reject the ICC. countries. … 8.3.3.1 TA1 TA1 conveys the values of FI and DI where:
  • the m.s. nibble FI is used to determine the value of F, the clock rate conversion factor, which may be used to modify the frequency of the clock provided by the terminal subsequent to the answer to reset
  • the l.s. nibble DI is used to determine the value of D, the bit rate adjustment factor, which may be used to adjust the bit duration used subsequent to the answer to reset See section 7.1 for calculation of the bit duration subsequent to the answer to reset (current etu). Default values of FI = 1 and DI = 1 indicating values of F = 372 and D = 1, respectively, shall be used during the answer to reset. From January 2021, 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 F = 372 and D = 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 indicating a value of D greater than or equal to 4. In such case the warm ATR shall be a basic ATR. From January 2021, ICCs returning a cold or warm ATR different than explained above are not compliant to this specification. Basic response: The ATR shall not contain TA1 and thus the default values of F = 372 and D = 1 shall continue 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: countries.
  • Accept the ATR if the value of TA1 is in the range '11' to '13',6 and immediately implement the values of F and D indicated (F=372 and D = 1, 2, or 4).
  • Reject the ATR if the value of TA1 is not in the range '11' to '13', unless it is able to support and immediately implement the conditions indicated. 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 using the default values of D = 1 and F = 372 during all subsequent exchanges, unless it supports a proprietary technique for negotiating the parameters to be used. If TA1 is absent from the ATR, the default values of D = 1 and F = 372 shall be used during all subsequent exchanges. … 8.3.3.3 TC1 … If the value of TC1 = 'FF', then the minimum character to character duration for subsequent transmissions shall be 12 etus if T=0 is to be used, or 11 etus if T=1 is to be used. From January 2021, an ATR containing TC1 having values other than '00' or 'FF' is not compliant to this specification. Basic response: Until end December 2020, Tthe ATR shall contain TC1 having a value in the range '00' to 'FF' and from January 2021, the ATR shall contain TC1 having a value '00' or 'FF'. Terminal behaviour: The terminal shall accept an ATR not containing TC1 (provided that b7 of T0 is set to 0), and shall continue the card session as though TC1 = '00' had been returned. Until end December 2020, Tthe basic response coding of character TC1 is shown in Table 20: b8 b7 b6 b5 b4 b3 b2 b1 x x x x x x x x countries. Table 20: Basic Response Coding of Character TC1 From January 2021, the basic response coding of character TC1 is shown in Table 20a: b8 b7 b6 b5 b4 b3 b2 b1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 Table 20a: Basic Response Coding of Character TC1 Note: It is strongly recommended that until end December 2020 the value of TC1 be set to the minimum acceptable for the ICC. Large values of TC1 lead to very slow communication between the terminal and the ICC, and thus lengthy transaction times.

8.3.3.4 TD1 … Basic responses: The ATR shall not contain TD1 if T=0 only is to be used, and protocol type T=0 shall be used as a default for all subsequent transmissions. The ATR shall contain TD1 = '81' if T=1 only is to be used, indicating that TD2 is present and that protocol type T=1 shall be used for all subsequent transmissions. Note: It is strongly recommended that the ATR contains a TD1 with a value of 'x1' indicating that protocol type T=1 shall be used for all subsequent transmissions for optimum performance and as T=0 protocol may not be supported in future versions of this specification. Terminal behaviour: The terminal shall accept an ATR containing TD1 with the m.s. nibble having any value (provided that the value returned correctly indicates and is consistent with the interface characters TA2 to TD2 actually returned), and the l.s. nibble having a value of '0' or '1'. The terminal shall reject an ATR containing other values of TD1. …

countries.

8.3.3.9 TA3 TA3 (if T=1 is indicated in TD2) returns the information field size integer for the ICC (IFSI), which determines the IFSC, and specifies the maximum length of the information field (INF) of blocks that can be received by the card. It represents the length of IFSC in bytes, and until end December 2020 may take any value between '01' and 'FE', and from January 2021, between '7C' and 'FE'. Values of '00' and 'FF' are reserved for future use. From January 2021, a T=1 ATR not having TA3 or having TA3 &lt; '7C' is not compliant to this specification. Basic response: If T=1 is to be used, the ATR shall contain TA3 having a value until end December 2020 in the range '10' to 'FE', and from January 2021, in the range '7C' to 'FE' indicating an initial IFSC. The value of IFSC indicates in the range 16 to 254 bytes until end December 2020, and from January 2021, the range 124 to 254 bytes. Terminal behaviour: The terminal shall accept an ATR not containing TA3 (provided that b5 of TD2 is set to 0), and shall continue the card session using a value of '20' for TA3. The terminal shall reject an ATR containing TA3 having a value in the range '00' to '0F' or a value of 'FF'. The terminal shall accept an ATR containing TA3 having a value in the range '10' to 'FE'. Until end December 2020, Tthe basic response coding of character TA3 is shown in Table 23: b8 b7 b6 b5 b4 b3 b2 b1 T=1 x x x x x x x x '00' to '0F' and 'FF' not allowed Table 23: Basic Response Coding of Character TA3

countries.

From January 2021, the basic response coding of character TA3 is shown in Table 23a: b8 b7 b6 b5 b4 b3 b2 b1 T=1 x x x x x x x x '00' to '7B' and 'FF' not allowed Table 23a: Basic Response Coding of Character TA3 8.3.3.10 TB3 TB3 (if T=1 is indicated in TD2) indicates the values of the CWI and the BWI used to compute the CWT and BWT respectively. The l.s. nibble (b1–b4) is used to indicate the value of CWI, whilst the m.s. nibble (b5–b8) is used to indicate the value of BWI. From January 2021, an ATR having CWI &gt; '1' is not compliant to this specification. Note: It is recommended that CWI = 0 for optimum performance. Basic response: If T=1 is to be used, the ATR shall contain TB3 having

  • until end December 2020, the l.s. nibble in the range '0' to '5', indicating values of 0 to 5 for CWI, and
  • from January 2021, the l.s. nibble '0' or '1' indicating values of 0 or 1 for CWI, and
  • the m.s. nibble in the range '0' to '4', indicating values of 0 to 5 for CWI and 0 to 4 for BWI. Until end December 2020, Tthe basic response coding of character TB3 is shown in Table 24: countries. b8 b7 b6 b5 b4 b3 b2 b1 T=1 0 x x x 0 y y y xxx is in the range 000 to 100 yyy is in the range 000 to 101 Table 24: Basic Response Coding of Character TB3 From January 2021, the basic response coding of character TB3 is shown in Table 24a: b8 b7 b6 b5 b4 b3 b2 b1 T=1 0 x x x 0 0 0 y xxx is in the range 000 to 100 y is 0 or 1 Table 24a: Basic Response Coding of Character TB3 Terminal behaviour: The terminal shall reject an ATR not containing TB3, or containing a TB3 indicating BWI greater than 4 and/or CWI greater than 5, or until end December 2021 having a value such that 2CWI ≤ (N + 1), and from January 2022, 2CWI &lt; (N + 1). It shall accept an ATR containing a TB3 having any other value. Note: N is the extra guardtime indicated in TC1. When using T=1, if TC1='FF', the value of N shall be taken as –1. Since the maximum value for CWI allowed by thesethis specifications is 5 until end December 2020, note that when T=1 is used, TC1 shall have a value in the range '00' to '1E' or a value of 'FF' up to that date in order to avoid a conflict between TC1 and TB3. From January 2021, if TC1 is not contained in the ATR or TC1='00' the value of CWI shall be 1 in order to avoid the interpretation of a conflict between TC1 and TB3 by legacy terminals. … 9.2.4.2.2 Timing for T=1 … The maximum interval between the leading edges of the start bits of two consecutive characters sent in the same block (the character waiting time, CWT) shall not exceed (2CWI+ 11) etus. Until end December 2020, Tthe character waiting countries. time integer, CWI shall have a value of 0 to 5, and from January 2021, a value of 0 or 1 as described in section 8.3.3.10, and thus CWT lies in the range 12 to 43 etus, and from January 2021, 12 or 13 etus. Terminals shall be able to correctly interpret CWI up to 5. The receiver shall be able to correctly interpret a character having a maximum interval between the leading edge of the start bit of the character and the leading edge of the start bit of the previous character of
(CWT + 4) etus. … 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.