You are on page 1of 27

© Gilbarco Veeder Root

AGENDA

• EMV General Overview


1

• EMV Securities Benefits


2

• EMV Transaction Flow


3

© Gilbarco Veeder Root


EMV General Overview

What is EMV?
• EMV is an internationally agreed standard for payment cards
• The name EMV is an acronym of ”Europay MasterCard Visa”
• The main purpose of the EMV standard is to introduce a more secure payment
method by using a chip card instead of a magnetic stripe card
• The risk with regard to fraudulent transactions is much higher when magnetic
stripe cards are being used
• This risk will be shifted to them who do not support the EMV functionality
Points of sale
Card Issuers

© Gilbarco Veeder Root


EMV Payment System Model

• Issuer (ex.g. banks, oil companies)


• Issue chip cards to the payment system
• Acquirers (ex. g. Luottokunta)
• Release payment accepting terminals to merchants
• Process the terminal transactions
• Pay the merchants for the transactions
• Merchant
• Obtain terminals that accept EMV Payments
• Cardholder

© Gilbarco Veeder Root


EMV Security Mechanisms

 The actual EMV functionality for authorising transactions resides with the
issuing bank
• Authorisation requests
 Asymmetric algorithms
• Authenticate the card as valid to the terminal
Symmetric algorithms
• Generate and verify transaction cryptograms based on key shared
between the card and the issuer bank

© Gilbarco Veeder Root


EMV Security Benefits

• EMV financial transactions are more secure


against fraud than traditional credit card payments

• Encryption algorithms such as DES, Triple-DES,


RSA and SHA to provide authentication of the card to the
processing terminal and the transaction processing center.

© Gilbarco Veeder Root


EMV Security Benefits

• EMV processing is generally slower than an


equivalent magnetic stripe transaction.

•EMV increased protection from fraud has allowed banks and


credit card issuers to push through a 'liability shift' such that
merchants are now liable (as from 1 January 2005 in the EU
region) for any fraud that results from transactions on systems
that are not EMV capable

© Gilbarco Veeder Root


EMV VS MAGNETIC STRIPE
• During a magnetic stripe transaction, the card itself functions as no more
than a static data storage device that is read by the terminal.
The terminal then performs all the processing and applies the rules
or payment.
• magnetic stripe technology does not possess the capability to verify the
authenticity of the card itself – is it a counterfeit card being used for
fraudulent purchases? This weakens the value of both the PIN or signature
cardholder verification methods.
• Unlike their magnetic stripe counterparts, EMV cards contain an embedded
micro processor chip that has the ability to encrypt transaction data
dynamically for each purchase And because the transaction information is
encoded differently every time, it’s harder for criminals to skim or copy
useful payment data and use it again for another fraudulent purchase.

© Gilbarco Veeder Root


EMV VS MAGNETIC STRIPE
• EMV provides provides the type of two-factor authentication. Card
authentication (cryptogram in the chip itself is used to authenticate the
card’s value) and cardholder verification (PIN or Signature).

© Gilbarco Veeder Root


Transaction Flow

© Gilbarco Veeder Root


Initiate Application

• Answer To Reset
Use the function to reset a Smart Card by EMV 2000 Standard. A Smart
Card reset allows the terminal to receive the Smart Card's
communication parameters from the application (e.g. data - baud rate,
size of data, protocol type etc.) and store this data in a buffer.

• Application Selection
Application selection process performed immediately after contact
activation/reset of the card and prior to 1st Application function. The
application selection is the process by which the terminal uses data in
the ICC according to protocol defined to determine the terminal
program. This process is defined in two steps:-
1. Create a list of ICC Application that are supported by the terminal.
2. Select the application to be run from the list generated above.

© Gilbarco Veeder Root


Initiate Application

• Initialize Application Processing

• Inform the ICC that processing of new transaction is beginning.


• Provides to the ICC the Terminal related information about the transaction.
• Obtain from the ICC the Application Interchange profile and a list of files that contain the ICC data
to be used in processing transaction.
• Determine whether the transaction is allowed

© Gilbarco Veeder Root


Read Application Data
• Data Contained in the files in ICC are required by the terminal to perform the various function
used in transaction processing.

– Sequence of Execution:
– The Read Application Data function is performed immediately following the
– Initiate Application Processing function.

© Gilbarco Veeder Root


Offline data Authentication

• Offline data authentication describes what kind of authentication will be


performed,and how the failure and success of authentication affects the
transaction flow and data recorded in the TVR and TSI.

• Availability of data in the ICC to support offline data authentication is


optional; its presence is indicated in the Application Interchange Profile.

• If both the terminal and the ICC support offline data authentication, the
terminal shall
• perform this function. Depending on the capabilities of the card and the terminal,
• SDA or DDA or CDA is performed.

© Gilbarco Veeder Root


Processing Restrictions

• Purpose:
The purpose of the Processing Restrictions function is to determine the degree of
compatibility of the application in the terminal with the application in the ICC
and to make any necessary adjustments, including possible rejection of the
transaction.
• Conditions of Execution:
The terminal shall always execute this function.
• Sequence of Execution:
Functions described here may be performed at any time after Read Application
Data and prior to completion of the terminal action analysis.
• Description:
The Processing Restrictions function comprises the following compatibility
checks:
• Application Version Number
• Application Usage Control
• Application Effective/Expiration Dates Checking

© Gilbarco Veeder Root


Cardholder Verification

Cardholder verification is performed to ensure that the person presenting the


ICC is the person to whom the application in the card was issued.

• Offline PIN Processing


• Online PIN Processing
• Signature Processing
• Combination CVMs

© Gilbarco Veeder Root


Terminal Risk Management

Terminal risk management consists of:


• Floor limit checking
• Random transaction selection
• Velocity checking
If both the Lower Consecutive Offline Limit (tag '9F14') and Upper Consecutive
Offline Limit (tag '9F23') exist, the terminal shall perform velocity checking
If either of these data objects is not present in the ICC application, the terminal shall skip this
section.

© Gilbarco Veeder Root


Terminal Action Analysis
Purpose:
Once terminal risk management and application functions related to a normal
offline transaction have been completed, the terminal makes the first decision as
to whether the transaction should be approved offline, declined offline, or
transmitted online.
• If the outcome of this decision process is to proceed offline, the terminal issues
a GENERATE AC command to ask the ICC to return a TC.
• If the outcome of the decision is to go online, the terminal issues a
GENERATE AC command to ask the ICC for an Authorisation Request
Cryptogram (ARQC).
• If the decision is to reject the transaction, the terminal issues a GENERATE
AC to ask for an Application Authentication Cryptogram (AAC).
An offline decision made here is not final. If the terminal asks for a TC from the
ICC, the ICC, as a result of card risk management, may return an ARQC or AAC.

© Gilbarco Veeder Root


Card Action Analysis
Purpose:
An ICC may perform its own risk management to protect the issuer from fraud or
excessive credit risk.

Conditions of Execution:
The card online/offline decision is specified by its response to the GENERATE AC
command. Therefore, this section applies to all transactions. Whether the ICC
performs any risk management tests is transparent to the terminal and outside
the scope of this specification.

Description:
The result of risk management performed by the ICC is a decision for one of the
following actions to be taken by the terminal:
• Approve the transaction offline. This option is available to the ICC only if the
terminal has made a preliminary decision to complete the transaction offline,
• Complete the transaction online.
• Request a referral.
• Reject the transaction.

© Gilbarco Veeder Root


Online Processing

Purpose:
Online processing is performed to ensure that the issuer can review and
authorise or reject transactions that are outside acceptable limits of risk defined
by the issuer, the payment system, or the acquirer.

Conditions of Execution:
Online processing shall be performed if the ICC returns an ARQC in response to
the first GENERATE AC command for the transaction.

Sequence of Execution:
The online processing function is performed when the terminal receives an ARQC
in response to the first GENERATE AC command.

© Gilbarco Veeder Root


Issuer-to-Card Script

• An issuer may provide command scripts to be delivered to the ICC by the terminal to perform
functions that are not necessarily relevant to the current transaction but are important for the
continued functioning of the application in the ICC.
• Multiple scripts may be provided with an authorisation response, and each may contain any number
of Issuer Script Commands. Script processing is provided to allow for functions that are outside the
scope of this specification but are nonetheless necessary.
• A script may contain Issuer Script Commands not known to the terminal, but the terminal shall deliver
each command to the ICC individually according to this specification.

© Gilbarco Veeder Root


Completion

The completion function is always the last function in the transaction processing.
(Script processing may be performed after the completion function.)

Description:
The ICC indicates willingness to complete transaction processing by returning
either a TC or an AAC to either the first or second GENERATE AC command
issued by the terminal. If the terminal decides to go online, completion shall be
done when the second GENERATE AC command is issued.

© Gilbarco Veeder Root


SPOT COMMANDS FOR EMV:

Few hi- level commands to manage EMV-steps execution on SPOT

START_EMV
ACTION_EMV
OLA_EMV
END_EMV

© Gilbarco Veeder Root


SPOT COMMANDS FOR EMV:
COMMANDS FROM EPS:

START_EMV
• - (Build candidates list)
• - Application selection
• - Account Selection
• - Initiate application
• - Read application data
• - Data authentication
• - Processing restrictions

ACTION_EMV
• - Card holder offline verification
• - Terminal risk management
• -Terminal action analysis
• - Card action analysis
• - Completion

© Gilbarco Veeder Root


SPOT COMMANDS FOR EMV:

OLA_EMV
• - Online processing
• - Issuer’s script processing
• - Completion

END_EMV

© Gilbarco Veeder Root


Question…..

© Gilbarco Veeder Root


Thank You

© Gilbarco Veeder Root

You might also like