EMV

What is EMV?

EMV is a global standard for the processing of card payments using an Integrated Circuit Card (ICC), commonly known as a chip card or smart card, and ICC capable Point of Sale (POS) terminals and ATMs.

The EMV standard takes its name from the card schemes Europay, MasterCard, and Visa that developed it.

EMV Transaction Process

The steps of the EMV transaction process are summarised below and described more fully in following sections.

A terminal is assumed to be a PIN Entry Device (PED) or PIN pad.

1. Application Selection
An EMV transaction starts with the selection of a payment application, which should be supported by both the card and the terminal. An EMV card may contain multiple separate applications with different cryptographic keys such as POS, ATM and CAP. The terminal requests a list of supported applications. The application may be automatically selected or chosen by the cardholder.

An Application Identifier (AID) is used to uniquely identify an application on the card.

The Application Label and Application Preferred Name are used to display the name of an application.

2. Initiate Application Processing
The terminal retrieves the Application Interchange Profile (AIP) and Application File Locator (AFL). The AIP contains information about supported functions and the AFL tells the terminal which records (list of objects) should be read from the card to perform the transaction.

Most of the information returned by the card is encoded using Basic Encoding Rules - Tag Length Value (BER-TLV). This format encapsulates each object in a triplet containing the tag of the object (one or two bytes), the length (one byte) and the value (a sequence of bytes representing the object).

3. Read Application Data
The terminal reads the records specified in the AFL. The most important objects are the Card Risk Management Data Object List 1 (CDOL1) and the Cardholder Verification Method (CVM) List. The CDOL1 specifies which data should be included in the First Issuance GENERATE AC command during Card Action Analysis. The CVM list enumerates the methods that can be used to authenticate the card user (e.g. PIN or signature) during Cardholder Verification.

4. Processing Restrictions
Processing restrictions determine whether the card should be used. Three data elements read in the previous step are checked:

The Application Version Number is the number assigned by the payment system to an application

The Application Usage Control indicates the card issuer‘s specified restrictions on the geographic usage and services allowed for the application

The Application Effective/Expiration Dates indicate the date from which the application should be used and the date after which it expires

If any of these checks fail, the transaction is not necessarily declined. The terminal sets the appropriate bit in the Terminal Verification Results (TVR), the components of which form the basis of an accept/decline decision later in the transaction flow.

5. Offline Data Authentication
Offline data authentication is a cryptographic check to validate the card using public-key cryptography. There are three different processes that can be undertaken depending on the card:

Static data authentication (SDA) ensures data read from the card has been signed by the card issuer. This prevents modification of data, but does not prevent cloning.

Dynamic data authentication (DDA) provides protection against modification of data and cloning.

Combined DDA/generate application cryptogram (CDA) combines DDA with the generation of a card's application cryptogram to assure card validity. Support of CDA in devices may be needed, as this process has been implemented in specific markets. This process is not mandatory in terminals and can only be carried out where both card and terminal support it.

6. Cardholder Verification
Cardholder verification is used to determine whether the person presenting the card is the legitimate cardholder. EMV supports the following Cardholder Verification Methods (CVMs):

• Signature
• Offline plain text PIN
• Offline enciphered PIN
• Offline plain text PIN and signature
• Offline enciphered PIN and signature
• Online PIN
• No CVM required
• Fail CVM processing

The terminal uses a CVM list read from the card to determine the type of verification to be performed. The CVM list establishes a priority of CVMs to be used relative to the capabilities of the terminal. POS terminals vary in their support of CVM depending on their type and the country in which they are located.

7. Terminal Risk Management
Terminal risk management is only performed if there is a decision to be made whether a transaction should be authorised online or offline. Terminal risk management checks the transaction amount against a floor limit (above which transactions should be processed online). It is also possible to have a 1 in n online counter, and a check against a hot card list (which is only necessary for off-line transaction). If the result of any of these tests are positive, the terminal sets the appropriate bit in the Terminal Verification Results (TVR).

8. Terminal Action Analysis
The TVR are used to determine whether a transaction should be approved offline, sent online for authorization, or declined offline. The analysis is done using a combination of Terminal Action Codes (TACs) which are held in the terminal and Issuer Action Codes (IACs) which are read from the card.

9. Card Action Analysis
Card Action Analysis gives the card the opportunity to accept the terminal's action analysis or to decline a transaction or force online authorization.

One of the data objects read from the card at the Read Application step is CDOL1 (Card Data object List). This list of objects is used by the card to make a decision about whether to approve or decline a transaction and includes the transaction amount, currency, date, TVR tag and Unpredictable Number tag. The terminal sends this data and, using the GENERATE AC command (First Issuance), requests one of the following cryptograms from the card:

Transaction Certificate (TC) (Offline Approval)
Application Authentication Cryptogram (AAC) (Offline Decline)
Authorization Request Cryptogram (ARQC) (Online authorization)

The card generates an Application Cryptogram based on its decision. The Cryptogram Information Data contains the type of Application Cryptogram generated by the card.

If the card returns an ARQC, the transaction goes online for authorization. The card generates the ARQC which is sent by the terminal in the authorization request. The Application Cryptogram includes the Transaction Type (a code indicating the type of transaction), the Application Transaction Counter (ATC), which is a sequence counter identifying the transaction, Issuer Application Data (IAD) and a Message Authentication Code (MAC).

The card issuer responds to an ARQC request with an Authorization Response Code (ARC) indicating how the transaction should proceed, an Authorisation Response Cryptogram (ARPC), verifying the response source, and optionally an Issuer script (script commands to update the card).

The ARC and ARPC are sent by the terminal to the card using the EXTERNAL AUTHENTICATE command.

The card checks the ARPC and if successful updates its internal state to note that the issuer authorized the transaction.

The terminal then calls GENERATE AC again (Second Issuance) requesting a TC cryptogram from the card indicating that the transaction is approved.

10. Issuer Script Processing
If a card issuer wants to update a card after issuance it can send commands to the card using issuer script processing. Issuer scripts are encrypted between the card and the issuer, so are meaningless to the terminal. Issuer script can be used to block cards, or change card parameters.

11. Completion
The terminal does final processing to complete the transaction. If the CVM is 'Signature', the customer should be asked to sign the receipt.

EMV Specifications

The EMV specifications are managed, maintained and enhanced by EMVCo. The EMV 4.3 specifications consist of four books:

• Book 1 - Application Independent ICC to Terminal Interface Requirements
• Book 2 - Security and Key Management
• Book 3 - Application Specification
• Book 4 - Cardholder, Attendant, and Acquirer Interface Requirements