Q: 

What are the different data elements that indicate fallback; is

everything in DE55?

A: A combination of data elements (fields) and data must be used to

detect fallback. This will depend on the message format of the network
specification. Here are some general guidelines; check with the
particular message specification you are working with to see how to
apply this to your specific situation.

a)      Data Element 22 in an ISO8583 message is often known as the

POS Entry Mode. This field typically contains sub-elements that indicate
the terminal input capability and how the data was actually obtained from
the card. This field can indicate that the terminal supports chip (ICC) but
the data was read from the magnetic stripe. However, this combination
will be true when a legitimate magnetic stripe card is presented at a chip-
enabled terminal, so these two pieces of information alone do not
indicate fallback.

b)      The format of the track 2 data can be useful. When the track 2 is
read from the magnetic stripe, the field separator will be an equal sign
(“=”); when the track 2 equivalent data is obtained from the chip, the field
separator will be a capital D (“D”), since the data in the EMV tags stored
in the chip cannot contain special characters such as an equal sign. The
discretionary data part of the track 2 will not be the same in the magnetic
stripe as it is in the track 2 equivalent data from the chip. Based on the
format of the track 2 data, you can tell whether the chip was actually
read or not.

c)       The first byte of the service code in the track 2 will have a value of
1 or 5 for magnetic stripe cards, and 2 or 6 for most contact chip cards.

d)      If an ARQC is present, it is clear that the chip was read. Most
ISO8583-based network specifications will carry the ARQC (EMV Tag
9F26), and other critical EMV Tags, in Data Element 55. If DE55 is
present, the chip was read successfully.

e)      Some network specifications require the acquirer to place a

specific value in the request message indicating that the transaction is
fallback, so that combinations of the data and fields listed above do not
necessarily need to be interrogated by the issuer to determine fallback.

If there is no specific value in the message that indicates fallback, the

following combinations of data typically indicate fallback:
  POS Entry Mode (or similar field) indicates that the terminal input
capability = chip/ICC, but the chip was not read
 Track 2 data is from the magnetic stripe (field separator of “=”)
 Service code in track 2 indicates it is a chip card
 DE55 is not present

Q: If the service code on the magnetic stripe tells the POS that it is a
chip card, couldn’t the fake card be made with a service code that says it
is a mag stripe card, in an attempt to prevent fallback?

A: Criminals often skim the magnetic stripe from the chip card, and write
this data “as is” to a counterfeit card. In this case, it’s easy to see that
the track 2 indicates this should be a chip card. If the criminal was smart
enough to change the service code on the track 2 to show it’s a
magnetic stripe card, and create the counterfeit card that way, the
terminal would not try to read a chip, and would process the transaction
as magnetic stripe. It is then the issuer’s responsibility to detect that the
track 2 data they receive indicates this is a magnetic stripe card, but the
card was actually created as a chip card. Hopefully the issuer’s data
base will have some way to indicate that the card in question was
actually created as a chip card. This could be done by using different
BINs for chip cards, or by having a flag in the card record indicating this
is a chip card, or by the presence of EMV-related data in the card record.

Q: How is the ARQC generated?

A:The EMVCo specifications provide guidelines for this function; for

further information please refer to  www.emvco.com, EMV Integrated
Circuit Card Specifications for Payment Systems, Version 4.3
(November 2011), Book 2 Security and Key Management, Section 8.

Each individual chip specification (e.g., American Express AEIPS,

Discover D-PAS, MasterCard M/Chip, Visa VSDC specs) conforms to
the EMV specification, but explains the nuances for each of those card
brands in great detail, for example, how session keys are derived, and
what is the exact algorithm that is used when calculating the ARQC.
Contact each payment network to obtain a copy of their chip
specifications.

Q: For an EMV transaction, is the ARQC and ARPC validation done

before the original transaction (withdrawal, inquiry, purchase) or during
the transaction itself?
A: When a chip card is presented at a chip-enabled terminal, there is an
exchange of information between the card and the terminal to initiate the
transaction.  Once the ICC application is selected, the chip passes the
terminal a lot of information to use for the next steps of the transaction.
At this point, the terminal prompts the cardholder to enter the PIN (if a
PIN is required), select the transaction and amount, etc. When the
terminal has gathered all the necessary information, it sends data to the
chip and requests that the chip calculate the ARQC. The chip passes the
ARQC back to the terminal, and the transaction request (containing the
ARQC and other EMV Tags) is sent to the acquirer. The issuer validates
the ARQC and generates the ARPC as part of the authorization process,
and includes the ARPC in the response that is returned to the acquirer.
For more information on this process, refer to the EMV Integrated Circuit
Card Specifications for Payment Systems, Version 4.3 (November
2011):

 Book 1 Application Independent ICC to Terminal Interface

Requirements, Section 12, and
 Book 3 Application Specification, Section 10

Q: Which tags in the EMV data carry the ARQC and ARPC information?

A: The ARQC itself is in EMV Tag 9F26 (Application Cryptogram). The

EMV specifications mandate that certain EMV Tags must be used to
calculate the ARQC; therefore these must be carried in the request from
the acquirer to the issuer. Refer to EMV Integrated Circuit Card
Specifications for Payment Systems, Book 2, Section 8.1.1. In addition,
each of the card brands can add one or more tags; this typically includes
the CVM Results (EMV Tag 9F34). All of these Tags (plus Tag 9F26) are
often found in field 55 in an ISO 8583-based request message, but some
network specifications place them in a different field. Be sure to check
the network specifications you are working with to see where the EMV
data is located.

The ARPC will be part of EMV Tag 91 (Issuer Authentication Data),

which may contain information in addition to the ARPC, such as the
response code. Refer to the individual card brand chip specifications for
their requirements.

 
Q: Do the additional EMV card authentications that take place add
additional time to a transaction, or is it actually faster than typical mag
stripe CV/PIN validation?

A: When the issuer receives a transaction request that contains EMV

data and the ARQC, the authorization system will need to take some
additional steps (compared to a magnetic stripe transaction). These
steps include, but may not be limited to, the following:

 Check for fallback

 Verify the ARQC
 Generate the ARPC
 Verify the iCVV (the CVV/CVC in the chip instead of the CVV/CVC
in the magnetic stripe)
 Generate an issuer script if needed

The issuer’s Hardware Security Module (HSM) is responsible for

verifying the ARQC and generating the ARPC, so a call (consisting of a
request/response message pair) must be made to the HSM to perform
these functions. All of the steps listed above may add an extremely short
amount of time to the authorization process.

Q: Why is the ARPC recalculated after getting a negative response from

the issuer?

A: There are several ways to calculate an ARPC; refer to EMV

Integrated Circuit Card Specifications for Payment Systems, Book 2,
Section 8.2. In addition, each individual card brand’s chip specification
(e.g. American Express AEIPS, Discover D-PAS, MasterCard M/Chip,
Visa VSDC) specifies how the calculation is to be performed to conform
to the individual card brand rules. One common way to generate an
ARPC is to perform an XOR (exclusive-OR) operation using the ARQC
and the transaction response code.

In many authorization systems, the ARQC verification is performed fairly

early during the authorization process, since, if the ARQC cannot be
validated, the issuer may want to decline the transaction, so there is no
need to continue through the remaining authorization logic. To be
efficient, the request that is sent to the HSM can specify that the HSM is
to do two things: verify the ARQC, and, if that verification is successful,
generate the ARPC. At this point in the authorization logic, all
authorization logic checks (e.g., PIN verification, balance check,
lost/stolen check) may not have been performed, so it is not yet known
whether the transaction will ultimately be approved or declined. But since
the majority of transactions are normally approved, the HSM can be
instructed to assume the transaction will be approved, and generate the
ARPC using an approval response code. If indeed the transaction is
approved, the ARPC that was generated at the beginning of the
authorization process is valid and will be sent to the terminal; so only
one call to the HSM was required. If, however, subsequent authorization
processing results in the transaction being declined, a second call to the
HSM is required in order to recalculate the ARPC using the decline
response code. This is much more efficient that sending a request to the
HSM to verify the ARQC, then later sending another request to the HSM
to obtain the ARPC, for every transaction.

Q: Are both the online and offline PINs the same value?

A: When a card supports both online and offline PIN, the card can
certainly be configured so that all applications on the card use the same
PIN for both online and offline functions. It should be transparent to the
cardholder whether online PIN or offline PIN is being used. The vast
majority of cardholders would not understand the concept of an offline
PIN and an online PIN, or when to use one vs. the other, or having a
different PIN for each application on their card. Imagine a card where the
online PIN is 9876 but the offline PIN is 2222. The cardholder goes to an
ATM, where PIN verification is always performed online, and enters PIN
9876; the transaction is approved. The cardholder goes to a POS device
that does not support offline PIN verification (but the cardholder knows
nothing about this), enters PIN 9876, and the transaction is approved.
Then the cardholder goes to a POS device that does support offline PIN
verification (but again the cardholder knows nothing about this), enters
PIN 9876, and the terminal says the PIN is invalid (the PIN entered by
the cardholder does not match the offline PIN stored in the chip). This
introduces many opportunities for cardholder confusion and frustration;
so issuers should consider having a single PIN associated with a card,
regardless of how many applications or online/offline functions are
supported by that card.

Q: Is offline as secure as online? Does it take away from the security of

the card? By storing the PIN in the chip, does this reduce the security?
A: Some people believe that offline functions are actually MORE secure
than online functions. Data that is verified offline is not sent online to a
host for verification, so it is not in the transaction request and therefore
cannot be captured by someone who might be monitoring the
communications line. The sensitive data that is used by the chip card
when performing offline functions is stored securely in the chip; if you
were to insert a chip card into a card reader and connect that card
reader to your PC, you would not be able to access this sensitive data. 
Chip cards must undergo rigorous testing and pass multiple certifications
before they can be issued to a cardholder; these certifications ensure
that the hardware, software, and data are sufficiently protected and that
the card and its applications will work as expected in production.

Q: What is “chip and PIN”?

A: “Chip and PIN” refers to a chip card that supports EMV and typically
requires a PIN when performing a transaction. “Chip and PIN” is not an
EMV term; it was coined in some countries to refer to their particular
EMV implementation, where the decision was made to use PIN as the
primary CVM. EMV supports several cardholder verification methods
(CVMs): online PIN, offline PIN, signature and “No CVM required”.

Q: What is the difference between chip and signature, and chip and PIN
cards, and how they would be processed at a POS?

A: The issuer will personalize a chip card to support one or more CVMs
for each application on the card. The CVMs that the application supports
are found in the CVM List in the chip. An application might support online
PIN only, or online PIN and signature, or online PIN, signature, and “No
CVM”, or offline PIN, or any combination of the above, depending on the
issuer’s business requirements and where and how they believe the card
will be used.

Similarly, a POS device can support one or more CVMs, depending on

whether it has a PIN pad (obviously if there is no PIN pad, the device will
not support online or offline PIN!), the merchant’s business requirements
and preferences, and any requirements of the processor and/or
networks with which the merchant is affiliated.
When a chip card is presented at a chip-enabled POS terminal, the chip
card will provide the CVM List to the terminal for the selected application,
and the terminal will select a CVM that both the terminal and the chip
card support; typically this will be the mutually-supported (by the terminal
and the chip card) CVM that is “highest” in the CVM List in the chip.

If online or offline PIN is selected, the terminal must prompt the

cardholder to enter the PIN. If offline PIN is used, the PIN will be verified
between the terminal and the card; an encrypted PIN block will not be
sent to a host system for verification, although, if the transaction goes
online for authorization, the transaction request will contain an indicator
that offline PIN verification was performed, and whether or not it was
successful.  If online PIN is used, the encrypted PIN block will be sent to
a host system for verification, the same as would be done today with
online PIN for magnetic stripe cards.

If signature is selected, and the transaction is approved, a receipt will be

printed for the cardholder to sign, or the cardholder will be asked to sign
an electronic signature pad. This is the same from the user’s perspective
as the current process for signature transactions.

If “No CVM” is used (i.e. no PIN or signature is required), the transaction

will proceed the same as it does today (from the user’s perspective) for
magnetic stripe transactions requiring no CVM.

Q: Why is signature verification only available for offline authentication?

A: I do not believe this is true. Signature can certainly be used as a

method of cardholder verification for online transactions. In fact, there is
no “offline” signature CVM. It is possible for a transaction to be
authorized offline, and in that case, if a signature is required, the
cardholder must sign the receipt or the electronic signature pad as they
do today.  Even if a transaction goes online for authorization, and
signature is the CVM that is to be used, the signature will be obtained
the same way it is today.

Q: Do only EMV-enabled cards that support offline authentication have a

PIN change on the ICC of card?
A: Some issuers support PIN change today for magnetic stripe cards. 
This type of PIN change is for online PIN, i.e. when a PIN is entered at
the terminal (ATM or POS) for a transaction, the encrypted PIN is sent
online to a host system for verification.  For EMV/chip cards that support
online PIN (but NOT OFFLINE PIN), this process DOES NOT CHANGE.
PIN change at the ATM, in the branch, or via IVR can still be done as it
is today.

If the card contains an offline PIN, the issuer must provide a way for the
cardholder to change their PIN. This can be done via ATM or in the
branch (and potentially in other ways under certain circumstances). In
any case, if the card can also be used in situations where only the online
PIN can be used (e.g. at an ATM), this means that the PIN offset or
some other PIN-verification value must be stored on the host. The PIN in
the chip and the PIN value on the host system must be kept in sync,
because the cardholder would not understand having a different offline
PIN from an offline PIN.  If the cardholder changes their PIN at the ATM,
the PIN verification value on the host is updated, and the host system
must send a command to the chip card to update the PIN that is stored
in the chip. This is done via an issuer script, which is tacked onto the PIN
change response sent from the host to the terminal and forwarded by the
terminal to the chip card. When the chip card receives the response, it
will execute the PIN change command in the script, which updates the
offline PIN stored in the chip.

For more information on this topic, please see our online

presentation “EMV and PIN Change at the ATM”.

Q: A group of related questions was asked: Why do we need a common

AID? Can you please address the Durbin requirement for merchants to
select which network will process the transaction – is that being
implemented today? So is it true to say that routing is no longer
performed based on BIN? Is that the proposed common AID? Can you
please explain the difference between common AID and global AID?

A: This is a complex topic; the answers to these questions would require

more room to answer than is typical in a blog post. The common AIDs
are being introduced so merchants and acquirers can comply with Reg II
and continue to use existing routing logic, such as routing by BIN.
Please refer to the following for more information:

Paragon’s online presentation “EMV, Debit, and Durbin in the US”

EMV Migration Forum (EMF) Debit Technical Proposal

 

Q: What are examples of separate apps or programs on the chip?

A: An application contains the logic and parameters to be used when

initiating a transaction. This would include the allowed cardholder
verification method(s), risk management, the algorithm to be used when
calculating or verifying a cryptogram, and similar information. Not all
applications or programs use the same CVMs, algorithms, etc. For
example, one application might be more suited to ATMs and another to
POS, or one might be more suited to credit and another for debit. Some
examples of applications are:

 MasterCard Maestro
 MasterCard Cirrus
 MasterCard debit/credit
 Visa debit/credit
 Visa PLUS
 Visa Electron

Q: Who makes the choice of AID while performing an EMV transaction:

cardholder, merchant, or the chip?

A: The issuer will personalize the chip card to support one or more
applications. Each application will have an identifier, or AID. If there is
more than one application on the card, the issuer will prioritize each
application. The order of priority is up to the issuer, and is based on
business requirements and how and where the issuer believes the card
will typically be used. For each application, the issuer must also indicate
whether the terminal can automatically select the application without
asking the cardholder to do so, and whether the terminal can
automatically select the application without prompting the cardholder to
confirm that selection. If the issuer were to require the cardholder to
select or confirm an application, this would typically be confusing to
cardholders; imagine if you were at the ATM or POS device and you
were asked to choose between MasterCard Cirrus and MasterCard
debit.  So issuers often personalize their cards so the terminal can
handle the application selection automatically, without requiring any
selection of confirmation by the cardholder.
Similarly, each terminal will support one or more applications/AIDs. The
terminal will support the applications and AIDs for the networks the
terminal owner belongs to, where it makes sense. For example, if an
application did not support online PIN, it would not make sense for an
ATM to support that application, since online PIN is the only CVM
allowed at ATMs today.

The EMV specification states that a terminal “should” support the ability
to allow the cardholder to select or confirm the application proposed by
the terminal (EMV Integrated Circuit Card Specifications for Payment
Systems, Version 4.3, Book 1, Section 12.4). So it’s not
a requirement that terminals support this, but there will be a time in the
future when this is a very good idea, and that is when we have true
multi-application cards, e.g. a card with both a debit and credit
application on it. In this case, it would be important for the customer to
select debit vs. credit, otherwise they might be unpleasantly surprised if
the terminal selects cash advance with a credit application rather than
cash withdrawal with a debit application. Note that this selection is
different from the account selection (e.g. checking vs. savings) function
already offered at terminals.

When a chip card is presented at a chip-enabled terminal, the terminal

will ask the card to provide the terminal with a list of all the AIDs the card
supports. Based on this list, if no cardholder selection or confirmation is
required, the terminal will select the mutually-supported (by the terminal
and the card) application/AID that has the highest priority on the card. If
cardholder selection or confirmation is required by the application on the
card, AND it is supported by the terminal, that figures into how the
application/AID is selected.

Q: Regarding scripting: can I send both tag 71 and 72 at the same time?

A: Per the EMV specifications (EMV Integrated Circuit Card

Specifications for Payment Systems, Version 4.3, Book 3, Section 10.1),
“two separate script tags are available for use by the Issuer. Issuer
scripts with tag ‘71’ shall be processed prior to issuing the final
GENERATE AC command. Issuer scripts with tag ‘72’ shall be
processed after issuing the final GENERATE AC command.” Check with
the individual chip specification (e.g. MasterCard M/Chip, Visa VSDC,
Amex AEIPS, Discover D-PAS) for information on what each
specification supports and requires. As an example, MasterCard M/Chip
specification states that “issuers must send not more than one template
71 script or one template 72 script with each authorization request
response or financial transaction request response message, although
each script template may contain multiple script commands.” (M/Chip
Requirements, 20 September 2013, page 2-34).

Q: Why is there a limitation on 127-128 bytes for issuer scripts?

A: The EMV specifications state that the length of the command to the
chip and the length of the response from the chip may not exceed 256
bytes (see EMV Integrated Circuit Card Specifications for Payment
Systems, Version 4.3, Book 1, Section 9.4). Even though the tags are
BER-TLV encoded, these commands require a 1 byte length.  If the data
is to exceed 128, then this would make it a two byte length (according to
BER-DER encoding rules).  That is why there is a limit. For more
information, see EMV Integrated Circuit Card Specifications for Payment
Systems, Version 4.3, Book 3, Annex B, or search on “BER Encoding
Rules” on Wikipedia.