EMV data object specifications

In EMV specifications, a composite data object is called a template (for example, FCI Template). The data object length field specifies the number of bytes in the object value field. In the EMV standard, the length field is specified by one, two, or three bytes. If the highest bit of the leftmost byte of the length field is 0, the length field occupies one byte and defines the length of the value from 0 to 127. If the highest bit is 1, the subsequent bits determine the number of additional bytes used to represent the length field. The BER-TLV data encoding method described above allows for a specific data object to uniquely identify its identifier, size, and value. Thus, ber-TLV encoding is a universal means of data representation.

Lists of data objects
To execute a number of commands, the card requires transaction parameters and terminal capabilities. For most EMV applications, this data is required for the first and second GENERATE AC commands, as well as for the GET PROCESSING OPTIONS command. The list of data objects required to execute a command is generally called a Data Object List (DOL). For specific commands, the names of the lists are specified.

For example:

• * Card Risk Management Data Object List 1 (CDOL1) – list of data objects for the first GENERATE AC command
• * Card Risk Management Data Object List 2 (CDOL2) – list of data objects for the second GENERATE AC command

Processing Options Data Object List (PDOL) – a list of data objects for the GET PROCESSING OPTIONS command Any list of data objects is a list of tags and lengths of data objects to be passed to the map. All lists are written to the card during its personalization and read by the terminal using the READ RECORD command. The terminal sends only the values of the objects listed in the lists in the corresponding commands.

The payment operation begins with the terminal selecting the payment application on the card. To perform a transaction, it is necessary that the terminal supports the payment application that is located on the card. At the stage of selecting an application, the terminal verifies the existence of such an application (if there are several applications supported by the terminal on the card, the terminal and possibly the cardholder choose which one to use to perform the current transaction). There are two ways to select an application: selection via PSE (Payment System Environment) and direct selection. PSE is a list with the ID of 1PAY.SYS.DDF01, which lists all payment applications on the card. But PSE is optional. Therefore, the terminal can find on the map all the applications that it processes and make its list of candidates for processing. In any case, the SELECT command is used to select the application to be processed, as a result of which some data about the selected payment application is transmitted to the terminal.

Once the application is selected, the terminal initiates a transaction. To do this, the GET PROCESSING OPTIONS command is used, with the help of which the terminal tells the card the data it needs in order to determine the features of the operation being performed.2 in response to the GET PROCESSING OPTIONS command, the card informs the terminal of its transaction capabilities and terminal requirements (via the Application Interchange Profile – AIP) and provides links to the data that the terminal must read to successfully complete the transaction (defined in the Application File Locator – AFL).

This data is called File Control Information (FCI) and contains the application ID (AID), the application label and the preferred languages of communication between the terminal and the cardholder.

The data the card needs to initiate a transaction is defined in the Processing Options Data Object List (PDOL) provided in response to the SELECT command. If no data is needed from the terminal, there is no PDOL list, and no data is transferred with the GET PROCESSING OPTIONS command.