What is the EMVCo position on clock data transmission speeds and Protocol Parameter Selection (PPS)?
ISO allows variation of data transmission speeds by adjustment of the Clock Rate Conversion Factor (F) and the Bit Rate Adjustment Factor (D) – these parameters are returned in character TA1 in the Answer to Reset. EMV does not specifically support variation of F (F=1 is always used in EMV) though values other than 1 are not forbidden for proprietary use. For D however, values of 2 and 4 (allowing doubling and quadrupling of the data transfer rate respectively) are supported as well as the basic value of 1.
EMV version 4.2 June 2008 states in Book 1 section 184.108.40.206 (TA1) that 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’ (D of 1, 2 or 4). Therefore, terminals shall accept an ATR in specific mode with D=1, 2 or 4. Further it states that if the value of TA1 is not in the range '11' to ‘13’ it shall reject the ATR unless it is able to support and immediately implement the conditions indicated. Support for values of TA1 other than '11' to ‘13’ is thus allowed but is not required by these specifications. If negotiable mode is indicated (absence of TA2) terminals shall accept the ATR regardless of the value of TA1 but shall continue the transaction using values for F & D of F=1 & D=1.
Note that EMV does not specifically support PPS for the purposes of negotiating values for F & D, or indeed for the value of other parameters in the ATR. However, use of PPS or a similar mechanism is not forbidden if used for proprietary purposes.
What is the EMVCo position on lower voltage cards?
EMVCo has worked with the ISO/IEC JTC1/SC17/WG4 Working Group to develop a solution for supporting lower voltage technology Cards and Terminals in the EMVCo specifications. Amendments to Book 1 detailing the requirements to support lower voltages, together with a migration schedule for their introduction are available in the Bulletins sections of the EMVCo website. The requirements detailed in the Amendment have been incorporated into section 5 of Book 1 of EMV.
What behaviour is expected of the terminal when unexpected data is encountered during READ RECORD?
The EMV Integrated Circuit Card Specifications specify the required terminal behaviour when a terminal encounters expected and recognised data elements in a READ RECORD response. However, there are no specific requirements for the case when unexpected data is encountered in a READ RECORD response. In this event, as a general rule, the terminal should ignore the unexpected or unrecognised data (i.e. behave as though the data element had not been received) and attempt to process the transaction, subject to any other terminal checks or requirements that are defined within the Specifications (e.g. Book 3 section 10.2 fourth paragraph). The terminal may store unrecognised data for use by the overall terminal application.
What behaviour is expected of the terminal when erroneous or unexpected data is returned by the ICC during application selection?
In line with all other sections of EMV, during APPLICATION SELECTION, the basic principle is that the terminal should attempt to process a card unless it is unable to do so. In other words, it is not a requirement that the terminal ‘polices’ the card; so unless a specific behaviour is required of the terminal and described within EMV, the terminal should attempt to process the card.
An example of where a terminal is unable to continue processing a card would be the absence of mandatory data.
Section 11.3 of Book 1 describes the command and response structures of the SELECT command. The response to the SELECT command is the FCI of either the PSE, or a DDF or an ADF, and the data elements that may be returned in the FCI are listed in tables 43, 44 and 45.
EMV has allocated data elements to specific templates, and terminals would be expected to check that data elements are contained within the correct template. A data element only has meaning within EMV when found in the relevant template(s) as defined in the data dictionary and should be treated as unexpected data when it is received in a different template.
The order of tagged data elements within each of the templates is only for illustrative purposes. The actual order of tagged data elements within templates encountered by the terminal may be different from that described in the specifications and should not be treated by the terminal as an error.
Unexpected data elements (that is, those not listed in tables 43, 44 and 45 of Book 1) that appear in templates '6F', '84' or 'A5' (but outside of tag 'BF0C' – FCI Issuer Discretionary Data) may be ignored (i.e. treated as though the data element had not been received), subject to any other checks required to be made by terminals as described within EMV.
Does the order of Data Elements in templates matter?
The order of tagged data elements within each of the templates as shown within EMV is for illustrative purposes. The actual order of tagged data elements within templates encountered by the terminal may differ from that described in the Specifications and should not be treated by the terminal as an error. However, to avoid any potential interoperability issues, issuers are strongly recommended to follow the defined structure and order of the data elements as specified in EMV.
What are Selectable Kernel Configurations and when might Selectable Kernel Configurations be used?
Selectable Kernel Configurations is an optional terminal feature that allows terminals to support different capabilities for different transactions. For example, if allowed by the payment system, a terminal might support only 'No CVM Required' for low value transactions and support Signature and Offline PIN for higher value transactions. Previously EMV mandated that Terminal Capabilities be initialized before the terminal was placed in its operational state thus disallowing this transaction-by-transaction change. Selectable Kernel Configurations allows terminals to invoke appropriate type-approved kernel configurations dynamically in order to support the required terminal capabilities on a transaction-by-transaction basis. The determination of the invoked kernel configuration is based on characteristics of the transaction and the card such as RID or AID and the transaction amount.
The Selectable Kernel Configurations specification update defined rules around this switching of terminal capabilities:
All kernel configurations that can be selected must have been type approved
The selection of the kernel configuration must occur before the GET PROCESSING OPTIONS command. This means Terminal Type, Terminal Capabilities, and Additional Terminal Capabilities will accurately reflect the behaviour of the terminal if passed to the card in the GET PROCESSING OPTIONS command.
Terminal support for Selectable Kernel Configurations is optional.
The following are some other examples where Selectable Kernel Configurations might be used:
An Automated Teller Machine (ATM) that also sells train tickets. When the cardholder selects the cash option, the Terminal Capabilities would indicate CVM support for Online PIN only and no support for offline data authentication. The Terminal Type would be '14' (online-only). When the cardholder selects the ticket option, the Terminal Capabilities may indicate support for Offline PIN and offline data authentication with a terminal Type of '15' (offline with online capability).
POS terminals in a country must support Online PIN for transactions being routed through a country’s domestic debit network but must not support Online PIN for transactions routed through networks that do not support Online PIN. Terminal Capabilities could support Online PIN when the selected AID is for the domestic debit network but not have this support when the selected AID is for the other network.
Please note that the individual payment systems may have rules/requirements governing whether, and for what purpose, Selectable Kernel Configurations may be used.
What is the difference between Amount, Authorised (Binary) and Amount, Authorised (Numeric)? Which amount-related data element should be supported by the terminal?
EMV supports two different formats for Amount, Authorised and terminals must support both formats for the amount. Amount, Authorised (Binary), tag '81' is a 4-byte binary format number while Amount, Authorised (Numeric), tag '9F02' is a 6-byte numeric format number. Both represent the amount that is being authorised. The recommended set of data elements to be included in Application Cryptogram generation includes Amount, Authorised (Numeric) so the card is likely to request this tag in the CDOL1/CDOL2. However, nothing prevents the card from requesting Amount, Authorised (Binary) in the PDOL, DDOL, CDOL1, CDOL2 so EMV terminals must support both the binary and numeric formats of the amount.
Terminal Floor Limit, Amount Reference Currency, and CVM List values 'X' and 'Y' are expressed as 4-byte binary numbers. When the terminal is using these values for internal comparisons to the authorised amount, the terminal needs to use a binary representation of the amount field.
The maximum amount that can be expressed using Amount, Authorised (Numeric) is 999,999,999,999 (9,999,999.99 with two decimal positions) while the maximum amount that can be expressed using Amount, Authorised (Binary) is smaller, 4,294,967,295 (42,949,672.95 with two decimal positions). Either data element is considered sufficient as an authorisation amount.
What is the recommended Terminal Type for the following acceptance environments: currency exchange bureau, self check-out, and quasi-cash?
For these three example acceptance environments, EMVCo’s recommended Terminal Type is ‘22’ (Attended: Offline with online capability, controlled by merchant). [Published on September 2013]
How can a contact terminal supporting TRM floor limit checking be configured to actually bypass the check (in all realistic situations)?
For EMV contact, the terminal floor limit check, if performed, sets the 'Transaction exceeds floor limit' bit in the TVR to 1 if the transaction amount is greater than or equal to the Terminal Floor Limit.
The terminal can be configured to bypass the Terminal Floor Limit check by setting the Terminal Floor Limit to its maximum value. As a result, no realistic transaction amounts would exceed the floor limit, the TVR 'Transaction exceeds floor limit' bit would never be set, and no action (i.e., declining offline or sending online) would be taken by the terminal based on this check.
This argumentation remains valid if the terminal uses a transaction log to prevent split sales. [Published on July 2014]
How can a contact terminal supporting TRM random transaction selection be configured to actually bypass the check?
For EMV contact, the random transaction selection check, if performed, sets the 'Transaction selected randomly for online processing' bit in the TVR to 1 if the terminal randomly selects the transaction for online processing.
The terminal can be configured to bypass the Random Transaction Selection check by setting the Target Percentage to be Used for Biased Random Selection to 0 and the Maximum Target Percentage to be Used for Biased Random Selection to 0. As a result, no transactions would be randomly selected for online processing, the TVR 'Transaction selected randomly for online processing' bit would never be set, and no action (i.e., declining offline or sending online) would be taken by the terminal based on this check. [Published on July 2014]
How can a contact terminal with terminal type '22' and compliant with EMV version 4.3 be configured to only approve transactions that went online?
A contact terminal with terminal type '22' is by definition a terminal that can approve transactions offline and online. Such a terminal uses the TRM checks in combination with the TACs (and the IACs) to:
Allow a transaction to be approved offline,
Force a transaction to be approved online.
The TRM floor limit check in particular is used to define the offline or online modes of operation of these terminals, dependent on the transaction amount. If the terminal floor limit is set to zero, the terminal floor limit check will always result in the 'Transaction exceeds floor limit' bit in the TVR to be set to 1, whatever the actual transaction amount.
As a consequence, it is possible to configure such a terminal so that it would not approve transactions offline using the following values:
The terminal floor limit is set to zero,
The 'Transaction exceeds floor limit' bit in the TAC-Denial is set to 0 (byte 4 bit 8),
The 'Transaction exceeds floor limit' bit in the TAC-Online is set to 1 (byte 4 bit 8),
The 'Transaction exceeds floor limit' bit in the TAC-Default is set to 1 (byte 4 bit 8).
The first condition ensures that the 'Transaction exceeds floor limit' bit in the TVR is always set to 1, whatever the actual transaction amount
The second condition ensures that transactions are not declined if the 'Transaction exceeds floor limit' bit in the TVR is set to 1.
The third condition ensures that transactions are sent online for approval if the 'Transaction exceeds floor limit' bit in the TVR is set to 1 (i.e. always because of condition 1).
The last condition ensures that, if the terminal cannot go online for approval, then the transaction is declined if the 'Transaction exceeds floor limit' bit in the TVR is set to 1 (i.e. always because of condition 1).
With these settings, the contact terminal with terminal type '22' and compliant with EMV version 4.3 would never approve transactions offline. [Published on July 2014]