Hubbry Logo
EMVEMVMain
Open search
EMV
Community hub
EMV
logo
8 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
EMV
EMV
from Wikipedia

An EMV credit card
An EMV credit card

EMV is a payment method based on a technical standard for smart payment cards and for payment terminals and automated teller machines which can accept them. EMV stands for "Europay, Mastercard, and Visa", the three companies that created the standard.[1]

EMV cards are smart cards, also called chip cards, integrated circuit cards (ICC), or IC cards, which store their data on integrated circuit chips, in addition to magnetic stripes for backward compatibility. These include cards that must be physically inserted or "dipped" into a reader, as well as contactless cards that can be read over a short distance using near-field communication technology. Payment cards which comply with the EMV standard are often called chip and PIN or chip and signature cards, depending on the authentication methods employed by the card issuer, such as a personal identification number (PIN) or electronic signature. Standards exist, based on ISO/IEC 7816, for contact cards, and based on ISO/IEC 14443 for contactless cards (Mastercard Contactless, Visa PayWave, American Express ExpressPay).[2][better source needed]

History

[edit]
Wordmark of EMVCo, a consortium that manages EMV and related standards

Until the introduction of chip & PIN, all face-to-face credit or debit card transactions involved the use of a magnetic stripe or mechanical imprint to read and record account data, and a signature for purposes of identity verification. The customer hands their card to the cashier at the point of sale who then passes the card through a magnetic reader or makes an imprint from the raised text of the card. In the former case, the system verifies account details and prints a slip for the customer to sign. In the case of a mechanical imprint, the transaction details are filled in, a list of stolen numbers is consulted, and the customer signs the imprinted slip. In both cases the cashier must verify that the customer's signature matches that on the back of the card to authenticate the transaction.

Using the signature on the card as a verification method has a number of security flaws, the most obvious being the relative ease with which cards may go missing before their legitimate owners can sign them. Another involves the erasure and replacement of legitimate signature, and yet another involves the forgery of the correct signature.

The invention of the silicon integrated circuit chip in 1959 led to the idea of incorporating it onto a plastic smart card in the late 1960s by two German engineers, Helmut Gröttrup and Jürgen Dethloff.[3] The earliest smart cards were introduced as calling cards in the 1970s, before later being adapted for use as payment cards.[4][5] Smart cards have since used MOS integrated circuit chips, along with MOS memory technologies such as flash memory and EEPROM (electrically erasable programmable read-only memory).[6]

The first standard for smart payment cards was the Carte Bancaire B0M4 from Bull-CP8 deployed in France in 1986, followed by the B4B0' (compatible with the M4) deployed in 1989. Geldkarte in Germany also predates EMV. EMV was designed to allow cards and terminals to be backwardly compatible with these standards. France has since migrated all its card and terminal infrastructure to EMV.

EMV stands for Europay, Mastercard, and Visa, the three companies that created the standard. The standard is now managed by EMVCo, a consortium with control split equally among Visa, Mastercard, JCB, American Express, China UnionPay, and Discover.[7] EMVCo accepts public comment on its draft standards and processes, but also allows other organizations to become "Associates" and "Subscribers" for deeper collaboration.[8] JCB joined the consortium in February 2009, China UnionPay in May 2013,[9] and Discover in September 2013.[10]

The top vendors of EMV cards and chips are: ABnote (American Bank Corp), CPI Card Group, IDEMIA (from the merger of Oberthur Technologies and Safran Identity & Security (Morpho) in 2017), Gemalto (acquired by the Thales Group in 2019) Giesecke & Devrient and Versatile Card Technology.[11]

Differences and benefits

[edit]

There are two major benefits to moving to smart-card-based credit card payment systems: improved security (with associated fraud reduction), and the possibility for finer control of "offline" credit-card transaction approvals. One of the original goals of EMV was to provide for multiple applications on a card: for a credit and debit card application or an e-purse. Beginning in 2013, new-issue debit cards in the US contain two applications — a card association (Visa, Mastercard etc.) application, and a common debit application.[12]

EMV chip card transactions improve security against fraud compared to magnetic stripe card transactions that rely on the holder's signature and visual inspection of the card to check for features such as hologram. The use of a PIN and cryptographic algorithms such as Triple DES, RSA and SHA provide authentication of the card to the processing terminal and the card issuer's host system. The processing time is comparable to online transactions, in which communications delay accounts for the majority of the time, while cryptographic operations at the terminal take comparatively little time. The supposed increased protection from fraud has allowed banks and credit card issuers to establish a "liability shift", such that merchants are liable (as of 1 January 2005 in the EU region and 1 October 2015 in the US) for any fraud that results from transactions on systems that are not EMV-capable.[1][13][14] The majority of implementations of EMV cards and terminals confirm the identity of the cardholder (unless the card is being used for a contactless transaction) by requiring the entry of a personal identification number (PIN) rather than signing a paper receipt. Whether or not PIN authentication takes place depends upon the capabilities of the terminal and programming of the card.

When credit cards were first introduced, merchants used mechanical rather than magnetic portable card imprinters that required carbon paper to make an imprint. They did not communicate electronically with the card issuer, and the card never left the customer's sight. The merchant had to verify transactions over a certain currency limit by telephoning the card issuer. During the 1970s in the United States, many merchants subscribed to a regularly-updated list of stolen or otherwise invalid credit card numbers. This list was commonly printed in booklet form on newsprint, in numerical order, much like a slender phone book, yet without any data aside from the list of invalid numbers. Checkout cashiers were expected to thumb through this booklet each and every time a credit card was presented for payment of any amount, prior to approving the transaction, which incurred a short delay.[15]

Later [when?], terminal equipment at the merchant electronically contacted the card issuer, using information from the magnetic stripe to verify the card and authorize the transaction. This was much faster, but required the transaction to occur in a fixed location. Consequently, if the transaction did not take place near a terminal (in a restaurant, for example) the clerk or waiter had to take the card away from the customer and to the card machine. It was easily possible for a dishonest employee to swipe the card surreptitiously through a cheap machine that instantly recorded the information on the card and stripe; in fact, even at the terminal, a thief could bend down in front of the customer and swipe the card on a hidden reader. This made illegal cloning of cards relatively easy and a more common occurrence than before.[citation needed]

Since the introduction of payment card chip and PIN, cloning of the chip is not feasible; only the magnetic stripe can be copied, and a copied card cannot be used by itself on a terminal requiring a PIN. The introduction of chip and PIN coincided with wireless data transmission technology becoming inexpensive and widespread. In addition to mobile-phone-based magnetic readers, merchant personnel can now bring wireless PIN pads to the customer, so the card is never out of the cardholder's sight. Thus, both chip and PIN and wireless technologies can be used to reduce the risks of unauthorized swiping and card cloning.[16]

Chip and PIN vis-à-vis chip and signature

[edit]

Chip and PIN is one of the two verification methods that EMV enabled cards can employ.[15] Rather than physically signing a receipt for identification purposes, the user enters a personal identification number (PIN), typically of four to six digits in length. This number must correspond to the information stored on the chip or PIN at Host. Chip and PIN technology makes it much harder for fraudsters to use a found card, inasmuch as if someone steals a card, they are unable to make fraudulent purchases unless they know the PIN.

Chip and signature, on the other hand, differentiates itself from chip and PIN by verifying a consumer's identity with a signature.[17]

As of 2015, chip and PIN cards are common in most European countries (e.g., the UK, Ireland, France, Portugal, Finland and the Netherlands) as well as in Pakistan, Iran, Brazil, Colombia, Venezuela, India, Sri Lanka, Canada, Australia and New Zealand. Chip and signature cards are more common in the US, Mexico, parts of South America (such as Argentina and Peru) and some Asian countries (such as Taiwan, Hong Kong, Thailand, South Korea, Singapore, and Indonesia).[18][19]

Online, phone, and mail order transactions

[edit]

While EMV technology has helped reduce crime at the point of sale, fraudulent transactions have shifted to more vulnerable telephone, Internet, and mail order transactions—known in the industry as card-not-present or CNP transactions.[20] CNP transactions made up at least 50% of all credit card fraud.[21] Because of physical distance, it is not possible for the merchant to present a keypad to the customer in these cases, so alternatives have been devised, including

  • Software approaches for online transactions that involve interaction with the card-issuing bank or network's website, such as Verified by Visa and Mastercard SecureCode (implementations of Visa's 3-D Secure protocol). 3-D Secure is now being replaced by Strong customer authentication as defined in the European Second Payment Services Directive.
  • Creating a one-time virtual card linked to a physical card with a given maximum amount.
  • Additional hardware with keypad and screen that can produce a one-time password, such as the Chip Authentication Program.
  • Keypad and screen integrated into complex cards to produce a one-time password. Since 2008, Visa has been running pilot projects using the Emue card where the generated number replaces the code printed on the back of standard cards.[22]

As for which is faster, The New York Times explained that it's a matter of perception: While the chip method requires that the chip stay in the machine until the transaction and the authorization process is completed, the phone swipe method does the authorization in the background; a receipt starts coming out right away.[23]

Commands

[edit]

ISO/IEC 7816-3 defines the transmission protocol between chip cards and readers. Using this protocol, data is exchanged in application protocol data units (APDUs). This comprises sending a command to a card, the card processing it, and sending a response. EMV uses the following commands:

  • application block
  • application unblock
  • card block
  • external authenticate (7816-4)
  • generate application cryptogram
  • get data (7816-4)
  • get processing options
  • internal authenticate (7816-4)
  • PIN change / unblock
  • read record (7816-4)
  • select (7816-4)
  • verify (7816-4).

Commands followed by "7816-4" are defined in ISO/IEC 7816-4 and are interindustry commands used for many chip card applications such as GSM SIM cards.

Transaction flow

[edit]

An EMV transaction has the following steps:[24][independent source needed]

  1. Application selection
  2. Initiate application processing
  3. Read application data
  4. Processing restrictions
  5. Offline data authentication
  6. Certificates
  7. Cardholder verification
  8. Terminal risk management
  9. Terminal action analysis
  10. First card action analysis
  11. Online transaction authorization (only carried out if required by the result of the previous steps; mandatory in ATMs)
  12. Second card action analysis
  13. Issuer script processing

Application selection

[edit]

ISO/IEC 7816 defines a process for application selection. The intent of application selection was to let cards contain completely different applications—for example GSM and EMV. However, EMV developers implemented application selection as a way of identifying the type of product, so that all product issuers (Visa, Mastercard, etc.) must have their own application. The way application selection is prescribed in EMV is a frequent source of interoperability problems between cards and terminals. Book 1[25] of the EMV standard devotes 15 pages to describing the application selection process.

An application identifier (AID) is used to address an application in the card or Host Card Emulation (HCE) if delivered without a card. An AID consists of a registered application provider identifier (RID) of five bytes, which is issued by the ISO/IEC 7816-5 registration authority. This is followed by a proprietary application identifier extension (PIX), which enables the application provider to differentiate among the different applications offered. The AID is printed on all EMV cardholder receipts. Card issuers can alter the application name from the name of the card network.

List of applications:

Card scheme / payment network RID Product PIX AID
FBF-1886 (Denmark)[26] A000000001 Loyalty card 0001 A0000000010001
Danmønt (Denmark) A000000001 Cash card 1010 A0000000011010
Visa A000000003 Visa credit or debit 1010 A0000000031010
Visa Electron 2010 A0000000032010
V Pay 2020 A0000000032020
Plus 8010 A0000000038010
Mastercard A000000004 Mastercard credit or debit 1010 A0000000041010
Mastercard[27] 9999 A0000000049999
Maestro 3060 A0000000043060
Cirrus ATM card only 6000 A0000000046000
Chip Authentication Program Securecode 8002 A0000000048002
A000000005 Maestro UK
(formerly Switch)
0001 A0000000050001
A000000010 Mastercard (China, debit and credit cards)[note 1] 8888 A0000000108888
American Express A000000025 American Express 01 A00000002501
A000000790 AMEX CHINA (debit and credit cards) [note 2] 01 A00000079001
U.S. Debit (all interbank networks) (USA) A000000098 Visa-branded card 0840 A0000000980840
A000000004 Mastercard-branded card 2203 A0000000042203
A000000152 Discover-branded card 4010 A0000001524010
Menards Credit Card (store card) (USA) A000000817 Store card 002001 A000000817002001
LINK ATM network (UK) A000000029 ATM card 1010 A0000000291010
CB (France) A000000042 CB (credit or debit card) 1010 A0000000421010
CB (Debit card only) 2010 A0000000422010
JCB (Japan) A000000065 Japan Credit Bureau 1010 A0000000651010
Dankort (Denmark) A000000121 Dankort 1010 A0000001211010
VisaDankort 4711 A0000001214711
Dankort (J/speedy) 4712 A0000001214712
Mastercard Dankort 4713 A0000001214713
Consorzio Bancomat (Italy) A000000141 Bancomat/PagoBancomat 0001 A0000001410001
Diners Club/Discover A000000152 Diners Club/Discover 3010 A0000001523010
Banrisul (Brazil) A000000154 Banricompras Debito 4442 A0000001544442
SPAN2 (Saudi Arabia) A000000228 SPAN 1010 A0000002281010
Interac (Canada) A000000277 Debit card 1010 A0000002771010
Discover (USA) A000000324 ZIP 1010 A0000003241010
UnionPay (China) A000000333 Debit 010101 A000000333010101
Credit 010102 A000000333010102
Quasi-credit 010103 A000000333010103
Electronic cash 010106 A000000333010106
DK (Germany) A000000359 Girocard 1010028001 A0000003591010028001
EAPS Bancomat (Italy) A000000359 PagoBancomat 10100380 A00000035910100380
Verve (Nigeria) A000000371 Verve 0001 A0000003710001
The Exchange Network ATM network (Canada/USA) A000000439 ATM card 1010 A0000004391010
RuPay (India) A000000524 RuPay 1010 A0000005241010
Dinube (Spain) A000000630 Dinube Payment Initiation (PSD2) 0101 A0000006300101
MIR (Russia) A000000658 MIR Debit 2010 A0000006582010
MIR Credit 1010 A0000006581010
Edenred (Belgium) A000000436 Ticket Restaurant 0100 A0000004360100
eftpos (Australia) A000000384 Savings (debit card) 10 A00000038410
Cheque (debit card) 20 A00000038420
GIM-UEMOA


(Eight West African countries: Benin, Burkina Faso, Côte d'Ivoire, Guinea Bissau, Mali, Niger, Senegal, Togo)

A000000337 Retrait 01 000001 A000000337301000
Standard 01 000002 A000000337101000
Classic 01 000003 A000000337102000
Prepaye Online 01 000004 A000000337101001
Prepaye Possibile Offline 01 000005 A000000337102001
Porte Monnaie Electronique 01 000006 A000000337601001
meeza (Egypt) A000000732 meeza Card 100123 A000000732100123
Mercury (UAE) A000000529 Mercury Card 1010 A0000005291010
China T-Union A000000632 MOT Electronic Purse 010105 A000000632010105
MOT Electronic Cash 010106 A000000632010106

Initiate application processing

[edit]

The terminal sends the get processing options command to the card. When issuing this command, the terminal supplies the card with any data elements requested by the card in the processing options data objects list (PDOL). The PDOL (a list of tags and lengths of data elements) is optionally provided by the card to the terminal during application selection. The card responds with the application interchange profile (AIP), a list of functions to perform in processing the transaction. The card also provides the application file locator (AFL), a list of files and records that the terminal needs to read from the card.[citation needed]

Read application data

[edit]

Smart cards store data in files. The AFL contains the files that contain EMV data. These all must be read using the read record command. EMV does not specify which files data is stored in, so all the files must be read. Data in these files is stored in BER TLV format. EMV defines tag values for all data used in card processing.[28]

Processing restrictions

[edit]

The purpose of the processing restrictions is to see if the card should be used. Three data elements read in the previous step are checked: Application version number, Application usage control (this shows whether the card is only for domestic use, etc.), Application effective/expiration dates checking.[citation needed]

If any of these checks fails, the card 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. This feature lets, for example, card issuers permit cardholders to keep using expired cards after their expiry date, but for all transactions with an expired card to be performed on-line.[citation needed]

Offline data authentication (ODA)

[edit]

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:[citation needed]

  • 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.[citation needed]

EMV certificates

[edit]

To verify the authenticity of payment cards, EMV certificates are used. The EMV Certificate Authority[29] issues digital certificates to payment card issuers. When requested, the payment card chip provides the card issuer's public key certificate and Signed Static Application Data (SSAD)[30] to the terminal. The terminal retrieves the CA's public key from local storage and uses it to confirm trust for the CA and, if trusted, to verify the card issuer's public key was signed by the CA. If the card issuer's public key is valid, the terminal uses the card issuer's public key to verify the card's SSAD was signed by the card issuer.[31]

Cardholder verification

[edit]

Cardholder verification is used to evaluate whether the person presenting the card is the legitimate cardholder. There are many cardholder verification methods (CVMs) supported in EMV. They are[citation needed]

  • Signature
  • Offline plaintext PIN
  • Offline enciphered PIN
  • Offline plaintext PIN and signature
  • Offline enciphered PIN and signature
  • Online PIN
  • No CVM required
  • Consumer Device CVM
  • Fail CVM processing

The terminal uses a CVM list read from the card to determine the type of verification to perform. The CVM list establishes a priority of CVMs to use relative to the capabilities of the terminal. Different terminals support different CVMs. ATMs generally support online PIN. POS terminals vary in their CVM support depending on type and country.[citation needed]

For offline enciphered PIN methods, the terminal encrypts the cleartext PIN block with the card's public key before sending it to the card with the Verify command. For the online PIN method, the cleartext PIN block is encrypted by the terminal using its point-to-point encryption key before sending it to the acquirer processor in the authorization request message.

All offline methods are vulnerable to man-in-the-middle attacks. In 2017, EMVCo added support for biometric verification methods in version 4.3 of the EMV specifications.[32]

Terminal risk management

[edit]

Terminal risk management is only performed in devices where there is a decision to be made whether a transaction should be authorised on-line or offline. If transactions are always carried out on-line (e.g., ATMs) or always off-line, this step can be skipped. Terminal risk management checks the transaction amount against an offline ceiling limit (above which transactions should be processed on-line). It is also possible to have a 1 in an online counter, and a check against a hot card list (which is only necessary for off-line transactions). If the result of any of these tests is positive, the terminal sets the appropriate bit in the terminal verification results (TVR).[33]

Terminal action analysis

[edit]

The results of previous processing steps are used to determine whether a transaction should be approved offline, sent online for authorization, or declined offline. This is done using a combination of data objects known as terminal action codes (TACs) held in the terminal and issuer action codes (IACs) read from the card. The TAC is logically OR'd with the IAC, to give the transaction acquirer a level of control over the transaction outcome. Both types of action code take the values Denial, Online, and Default. Each action code contains a series of bits which correspond to the bits in the Terminal verification results (TVR), and are used in the terminal's decision whether to accept, decline or go on-line for a payment transaction. The TAC is set by the card acquirer; in practice card schemes advise the TAC settings that should be used for a particular terminal type depending on its capabilities. The IAC is set by the card issuer; some card issuers may decide that expired cards should be rejected, by setting the appropriate bit in the Denial IAC. Other issuers may want the transaction to proceed on-line so that they can in some cases allow these transactions to be carried out.[34][better source needed]

When an online-only device performs IAC-Online and TAC-Online processing the only relevant TVR bit is "Transaction value exceeds the floor limit". Because the floor limit is set to zero, the transaction should always go online and all other values in TAC-Online or IAC-Online are irrelevant. Online-only devices do not need to perform IAC-default processing. An online-only device such as an ATM always attempts to go on-line with the authorization request, unless declined off-line due to IAC-Denial settings. During IAC-Denial and TAC-Denial processing, for an online only device, the only relevant Terminal verification results bit is "Service not allowed".[35]

First card action analysis

[edit]

One of the data objects read from the card in the Read application data stage is CDOL1 (Card Data object List). This object is a list of tags that the card wants to be sent to it to make a decision on whether to approve or decline a transaction (including transaction amount, but many other data objects too). The terminal sends this data and requests a cryptogram using the generate application cryptogram command. Depending on the terminal's decision (offline, online, decline), the terminal requests one of the following cryptograms from the card:[citation needed]

  • Transaction certificate (TC)—offline approval
  • Authorization Request Cryptogram (ARQC)—online authorization
  • Application Authentication Cryptogram (AAC)—offline decline

This step gives the card the opportunity to accept the terminal's action analysis or to decline a transaction or force a transaction on-line. The card cannot return a TC when an ARQC has been asked for, but can return an ARQC when a TC has been asked for.[35]

Online transaction authorization

[edit]

Transactions go online when an ARQC has been requested. The ARQC is sent in the authorisation message. The card generates the ARQC. Its format depends on the card application. EMV does not specify the contents of the ARQC. The ARQC created by the card application is a digital signature of the transaction details, which the card issuer can check in real time. This provides a strong cryptographic check that the card is genuine. The issuer responds to an authorization request with a response code (accepting or declining the transaction), an authorisation response cryptogram (ARPC) and optionally an issuer script (a string of commands to be sent to the card).[35]

ARPC processing is not performed in contact transactions processed with Visa Quick Chip[36] for EMV and Mastercard M/Chip Fast,[37] and in contactless transactions across schemes because the card is removed from the reader after the ARQC has been generated.

Second card action analysis

[edit]

CDOL2 (Card data object list) contains a list of tags that the card wanted to be sent after online transaction authorisation (response code, ARPC, etc.). Even if for any reason the terminal could not go online (e.g., communication failure), the terminal should send this data to the card again using the generate authorisation cryptogram command. This lets the card know the issuer's response. The card application may then reset offline usage limits.

Issuer script processing

[edit]

If a card issuer wants to update a card post issuance it can send commands to the card using issuer script processing. Issuer scripts are meaningless to the terminal and can be encrypted between the card and the issuer to provide additional security. Issuer script can be used to block cards, or change card parameters.[38]

Issuer script processing is not available in contact transactions processed with Visa Quick Chip[36] for EMV and Mastercard M/Chip Fast,[37] and for contactless transactions across schemes.

EMV chip specification

[edit]
Contact pad for the electrical interface on the front side of a credit card

The first version of EMV standard was published in 1995. Now the standard is defined and managed by the privately owned corporation EMVCo LLC. The current members of EMVCo[39] are American Express, Discover Financial, JCB International, Mastercard, China UnionPay, and Visa Inc. Each of these organizations owns an equal share of EMVCo and has representatives in the EMVCo organization and EMVCo working groups.

Recognition of compliance with the EMV standard (i.e., device certification) is issued by EMVCo following submission of results of testing performed by an accredited testing house.[citation needed]

EMV Compliance testing has two levels: EMV Level 1, which covers physical, electrical and transport level interfaces, and EMV Level 2, which covers payment application selection and credit financial transaction processing.[citation needed]

After passing common EMVCo tests, the software must be certified by payment brands to comply with proprietary EMV implementations such as Visa VSDC, American Express AEIPS, Mastercard MChip, JCB JSmart, or EMV-compliant implementations of non-EMVCo members such as LINK in the UK, or Interac in Canada.[citation needed]

List of EMV documents and standards

[edit]

As of 2011, since version 4.0, the official EMV standard documents which define all the components in an EMV payment system are published as four "books" and some additional documents:

  • Book 1: Application Independent ICC to Terminal Interface Requirements[25]
  • Book 2: Security and Key Management[40]
  • Book 3: Application Specification[41]
  • Book 4: Cardholder, Attendant, and Acquirer Interface Requirements[42]
  • Common Payment Application Specification[43]
  • EMV Card Personalisation Specification[44]

Versions

[edit]

The first EMV standard came into view in 1995 as EMV 2.0. This was upgraded to EMV 3.0 in 1996 (sometimes referred to as EMV '96) with later amendments to EMV 3.1.1 in 1998. This was further amended to version 4.0 in December 2000 (sometimes referred to as EMV 2000). Version 4.0 became effective in June 2004. Version 4.1 became effective in June 2007. Version 4.2 is in effect since June 2008. Version 4.3 is in effect since November 2011.[45]

Vulnerabilities

[edit]

Opportunities to harvest PINs and clone magnetic stripes

[edit]

In addition to the track-two data on the magnetic stripe, EMV cards generally have identical data encoded on the chip, which is read as part of the normal EMV transaction process. If an EMV reader is compromised to the extent that the conversation between the card and the terminal is intercepted, then the attacker may be able to recover both the track-two data and the PIN, allowing construction of a magnetic stripe card, which, while not usable in a Chip and PIN terminal, can be used, for example, in terminal devices that permit fallback to magstripe processing for foreign customers without chip cards, and defective cards. This attack is possible only where (a) the offline PIN is presented in plaintext by the PIN entry device to the card, where (b) magstripe fallback is permitted by the card issuer and (c) where geographic and behavioural checking may not be carried out by the card issuer.[citation needed]

APACS, representing the UK payment industry, claimed that changes specified to the protocol (where card verification values differ between the magnetic stripe and the chip – the iCVV) rendered this attack ineffective and that such measures would be in place from January 2008.[46] Tests on cards in February 2008 indicated this may have been delayed.[47]

Successful attacks

[edit]

Conversation capturing is a form of attack which was reported to have taken place against Shell terminals in May 2006, when they were forced to disable all EMV authentication in their petrol stations after more than £1 million was stolen from customers.[48]

In October 2008, it was reported that hundreds of EMV card readers intended for use in Britain, Ireland, the Netherlands, Denmark, and Belgium had been tampered with in China during or shortly after manufacture. For nine months, details and PINs of credit and debit cards were sent over mobile phone networks to criminals in Lahore, Pakistan. United States National Counterintelligence Executive Joel Brenner said, "Previously only a nation state's intelligence agency would have been capable of pulling off this type of operation. It's scary." Stolen data was typically used a couple of months after the card transactions to make it harder for investigators to pin down the vulnerability. After the fraud was discovered it was found that tampered-with terminals could be identified as the additional circuitry increased their weight by about 100 grams. Tens of millions of pounds are believed to have been stolen.[49] This vulnerability spurred efforts to implement better control of POS devices over their entire lifecycle, a practice endorsed by electronic payment security standards like those being developed by the Secure POS Vendor Alliance (SPVA).[50]

PIN harvesting and stripe cloning

[edit]

In a February 2008 BBC Newsnight programme Cambridge University researchers Steven Murdoch and Saar Drimer demonstrated one example attack, to illustrate that Chip and PIN is not secure enough to justify passing the liability to prove fraud from banks onto customers.[51][52] The Cambridge University exploit allowed the experimenters to obtain both card data to create a magnetic stripe and the PIN.

APACS, the UK payments association, disagreed with the majority of the report, saying "The types of attack on PIN entry devices detailed in this report are difficult to undertake and not currently economically viable for a fraudster to carry out."[53] They also said that changes to the protocol (specifying different card verification values between the chip and magnetic stripe – the iCVV) would make this attack ineffective from January 2008.

In August 2016, NCR Corporation security researchers showed how credit card thieves can rewrite the code of a magnetic strip to make it appear like a chipless card, which allows for counterfeiting.[citation needed]

2010: Hidden hardware disables PIN checking on stolen card

[edit]

On 11 February 2010 Murdoch and Drimer's team at Cambridge University announced that they had found "a flaw in chip and PIN so serious they think it shows that the whole system needs a re-write" that was "so simple that it shocked them". A stolen card is connected to an electronic circuit and to a fake card which is inserted into the terminal ("man-in-the-middle attack"). Any four digits can be typed in and accepted as a valid PIN.[54][55]

A team from the BBC's Newsnight programme visited a Cambridge University cafeteria (with permission) with the system, and were able to pay using their own cards (a thief would use stolen cards) connected to the circuit, inserting a fake card and typing in "0000" as the PIN. The transactions were registered as normal, and were not picked up by banks' security systems. A member of the research team said, "Even small-scale criminal systems have better equipment than we have. The amount of technical sophistication needed to carry out this attack is really quite low." The announcement of the vulnerability said, "The expertise that is required is not high (undergraduate level electronics). We dispute the assertion by the banking industry that criminals are not sophisticated enough, because they have already demonstrated a far higher level of skill than is necessary for this attack in their miniaturized PIN entry device skimmers." It was not known if this vulnerability had been exploited, but it could explain unresolved cases of claimed fraud.[55]

EMVCo disagreed and published a response saying that, while such an attack might be theoretically possible, it would be extremely difficult and expensive to carry out successfully, that current compensating controls are likely to detect or limit the fraud, and that the possible financial gain from the attack is minimal while the risk of a declined transaction or exposure of the fraudster is significant.[56] The Cambridge team disagrees: they carried it out without the banks noticing, with off-the-shelf equipment with some non-sophisticated additions. Less bulky versions could easily be made. The ones producing such equipment for the attack need not put themselves at risk, but can sell it to anybody via the Internet.[55]

When approached for comment, several banks (Co-operative Bank, Barclays and HSBC) each said that this was an industry-wide issue, and referred the Newsnight team to the banking trade association for further comment.[57] According to Phil Jones of the Consumers' Association, Chip and PIN has helped to bring down instances of card crime, but many cases remain unexplained. "What we do know is that we do have cases that are brought forward from individuals which seem quite persuasive."[citation needed]

The attack uses the fact that the choice of authentication method is unauthenticated, which allows the man in the middle. The terminal asks for a PIN, gets it and gets the transaction confirmed by the card – which thinks it is doing a card-and-signature transaction, which could indeed succeed offline. It also works online, perhaps because of insufficient checks.[58]

Originally, bank customers had to prove that they had not been negligent with their PIN before getting redress, but UK regulations in force from 1 November 2009 placed the onus on banks to prove that a customer has been negligent in any dispute, with the customer given 13 months to make a claim.[59] Murdoch said that "[the banks] should look back at previous transactions where the customer said their PIN had not been used and the bank record showed it has, and consider refunding these customers because it could be they are victim of this type of fraud."[55]

2011: CVM downgrade allows arbitrary PIN harvest

[edit]

At the CanSecWest conference in March 2011, Andrea Barisani and Daniele Bianco presented research uncovering a vulnerability in EMV that would allow arbitrary PIN harvesting despite the cardholder verification configuration of the card, even when the supported CVMs data is signed.[60]

The PIN harvesting can be performed with a chip skimmer. In essence, a CVM list that has been modified to downgrade the CVM to Offline PIN is still honoured by POS terminals, despite its signature being invalid.[61]

PIN bypass

[edit]

In 2020, researchers David Basin, Ralf Sasse, and Jorge Toro from ETH Zurich reported[62][63] a security issue affecting Visa contactless cards: lack of cryptographic protection of critical data sent by the card to the terminal during an EMV transaction. The data in question determines the cardholder verification method (such as PIN verification) to be used for the transaction. The team demonstrated that it is possible to modify this data to trick the terminal into believing that no PIN is required because the cardholder was verified using their device (e.g. smartphone). The researchers developed a proof-of-concept Android app that effectively turns a physical Visa card into a mobile payment app (e.g. Apple Pay, Google Pay) to perform PIN-free, high-value purchases. The attack is carried out using two NFC-enabled smartphones, one held near the physical card and the second held near the payment terminal. The attack might affect cards by Discover and China's UnionPay but this was not demonstrated in practice, in contrast to Visa cards.

In early 2021, the same team disclosed that Mastercard cards are also vulnerable to a PIN bypass attack. They showed that criminals can trick a terminal into transacting with a Mastercard contactless card while believing it to be a Visa card. This card brand mixup has critical consequences since it can be used in combination with the PIN bypass for Visa to also bypass the PIN for Mastercard cards.[63]

Implementation

[edit]
An EMV chip semiconductor package on the side opposite to its contact pads
View of the chip, a die shot

EMV stands for "Europay, Mastercard, and Visa", the three companies that created the standard. The standard is now managed by EMVCo, a consortium of financial companies. [1] Additional widely known chips of the EMV standard are:

  • AEIPS: American Express
  • UICS: China Union Pay
  • J Smart: JCB
  • D-PAS: Discover/Diners Club International
  • Rupay: NPCI
  • Verve

Visa and Mastercard have also developed standards for using EMV cards in devices to support card not present transactions (CNP) over the telephone and Internet. Mastercard has the Chip Authentication Program (CAP) for secure e-commerce. Its implementation is known as EMV-CAP and supports a number of modes. Visa has the Dynamic Passcode Authentication (DPA) scheme, which is their implementation of CAP using different default values.

In many countries of the world, debit card and/or credit card payment networks have implemented liability shifts.[citation needed] Normally, the card issuer is liable for fraudulent transactions. However, after a liability shift is implemented, if the ATM or merchant's point of sale terminal does not support EMV, the ATM owner or merchant is liable for the fraudulent transaction.

Chip and PIN systems can cause problems for travellers from countries that do not issue Chip and PIN cards as some retailers may refuse to accept their chipless cards.[64] While most terminals still accept a magnetic strip card, and the major credit card brands require vendors to accept them,[65] some staff may refuse to take the card, under the belief that they are held liable for any fraud if the card cannot verify a PIN. Non-chip-and-PIN cards may also not work in some unattended vending machines at, for example, train stations, or self-service check-out tills at supermarkets.[66]

Africa

[edit]
  • Mastercard's liability shift among countries within this region took place on 1 January 2006.[67] By 1 October 2010, a liability shift had occurred for all point of sale transactions.[68]
  • Visa's liability shift for points of sale took place on 1 January 2006. For ATMs, the liability shift took place on 1 January 2008.[69]

South Africa

[edit]
  • Mastercard's liability shift took place on 1 January 2005.[67]

Asian and Pacific countries

[edit]
  • Mastercard's liability shift among countries within this region took place on 1 January 2006.[67] By 1 October 2010, a liability shift had occurred for all point of sale transactions, except for domestic transactions in China and Japan.[68]
  • Visa's liability shift for points of sale took place on 1 October 2010.[69] For ATMs, the liability shift date took place on 1 October 2015, except in China, India, Japan, and Thailand, where the liability shift was on 1 October 2017.[70] Domestic ATM transactions in China are not currently not subject to a liability shift deadline.

Australia

[edit]
  • Mastercard required that all point of sale terminals be EMV capable by April 2013. For ATMs, the liability shift took place in April 2012. ATMs must be EMV compliant by the end of 2015.[71]
  • Visa's liability shift for ATMs took place 1 April 2013.[69]

Malaysia

[edit]
  • Malaysia is the first country in the world to completely migrate to EMV-compliant smart cards two years after its implementation in 2005.[72][73]

New Zealand

[edit]
  • Mastercard required all point of sale terminals to be EMV compliant by 1 July 2011. For ATMs, the liability shift took place in April 2012. ATMs are required to be EMV compliant by the end of 2015.[71]
  • Visa's liability shift for ATMs was 1 April 2013.[69]

Europe

[edit]
  • Mastercard's liability shift took place on 1 January 2005.[67]
  • Visa's liability shift for points of sale took place on 1 January 2006. For ATMs, the liability shift took place on 1 January 2008.[69]
  • France has cut card fraud by more than 80% since its introduction in 1992 (see Carte Bleue).

United Kingdom

[edit]
Green rectangle containing a row of four white asterisks in black squares; the outline of a hand points to and obscures the second asterisk.
Chip and PIN UK logo

Chip and PIN was trialled in Northampton, England from May 2003,[74] and as a result was rolled out nationwide in the United Kingdom on 14 February 2006[75] with advertisements in the press and national television touting the "Safety in Numbers" slogan. During the first stages of deployment, if a fraudulent magnetic swipe card transaction was deemed to have occurred, the retailer was refunded by the issuing bank, as was the case prior to the introduction of Chip and PIN. On January 1, 2005, the liability for such transactions was shifted to the retailer; this acted as an incentive for retailers to upgrade their point of sale (PoS) systems, and most major high-street chains upgraded on time for the EMV deadline. Many smaller businesses were initially reluctant to upgrade their equipment, as it required a completely new PoS system—a significant investment.

New cards featuring both magnetic strips and chips are now issued by all major banks. The replacement of pre-Chip and PIN cards was a major issue, as banks simply stated that consumers would receive their new cards "when their old card expires" — despite many people having had cards with expiry dates as late as 2007. The card issuer Switch lost a major contract with HBOS to Visa, as they were not ready to issue the new cards as early as the bank wanted.

The Chip and PIN implementation was criticised as designed to reduce the liability of banks in cases of claimed card fraud by requiring the customer to prove that they had acted "with reasonable care" to protect their PIN and card, rather than on the bank having to prove that the signature matched. Before Chip and PIN, if a customer's signature was forged, the banks were legally liable and had to reimburse the customer. Until 1 November 2009 there was no such law protecting consumers from fraudulent use of their Chip and PIN transactions, only the voluntary Banking Code. There were many reports that banks refused to reimburse victims of fraudulent card use, claiming that their systems could not fail under the circumstances reported, despite several documented successful large-scale attacks.[citation needed]

The Payment Services Regulations 2009 came into force on 1 November 2009[76] and shifted the onus onto the banks to prove, rather than assume, that the cardholder is at fault.[59] The Financial Services Authority (FSA) said "It is for the bank, building society or credit card company to show that the transaction was made by you, and there was no breakdown in procedures or technical difficulty" before refusing liability.

Latin America and the Caribbean

[edit]
  • Mastercard's liability shift among countries within this region took place on 1 January 2005.[67]
  • Visa's liability shift for points of sale took place on 1 October 2012, for any countries in this region that had not already implemented a liability shift. For ATMs, the liability shift took place on 1 October 2014, for any countries in this region that had not already implemented a liability shift.[69]

Brazil

[edit]
  • Mastercard's liability shift took place on 1 March 2008.[67]
  • Visa's liability shift for points of sale took place on 1 April 2011. For ATMs, the liability shift took place on 1 October 2012.[69]

Colombia

[edit]
  • Mastercard's liability shift took place on 1 October 2008.[67]

Mexico

[edit]
  • Discover implemented a liability shift on 1 October 2015. For pay at the pump at gas stations, the liability shift was on 1 October 2017.[77]
  • Visa's liability shift for points of sale took place on 1 April 2011. For ATMs, the liability shift took place on 1 October 2012.[69]

Venezuela

[edit]
  • Mastercard's liability shift took place on 1 July 2009.[67]

Middle East

[edit]
  • Mastercard's liability shift among countries within this region took place on 1 January 2006.[67] By 1 October 2010, a liability shift had occurred for all point of sale transactions.[68]
  • Visa's liability shift for points of sale took place on 1 January 2006. For ATMs, the liability shift took place on 1 January 2008.[69]

North America

[edit]

Canada

[edit]
  • American Express implemented a liability shift on 31 October 2012.[1][78]
  • Discover implemented a liability shift on 1 October 2015 for all transactions except pay-at-the-pump at gas stations; those transactions shifted on 1 October 2017.[77][independent source needed]
  • Interac (Canada's debit card network) stopped processing non-EMV transactions at ATMs on 31 December 2012, and mandated EMV transactions at point-of-sale terminals on 30 September 2016, with a liability shift taking place on 31 December 2015.[79][failed verification][independent source needed]
  • Mastercard implemented domestic transaction liability shift on 31 March 2011, and international liability shift on 15 April 2011. For pay at the pump at gas stations, the liability shift was implemented 31 December 2012.[78]
  • Visa implemented domestic transaction liability shift on 31 March 2011, and international liability shift on 31 October 2010. For pay at the pump at gas stations, the liability shift was implemented 31 December 2012.[78]
  • Over a five-year period post-EMV migration, domestic card-card present fraudulent transactions significantly reduced in Canada. According to Helcim's reports, card-present domestic debit card fraud reduced 89.49% and credit card fraud 68.37%.[1][80]

United States

[edit]

After widespread identity theft due to weak security in the point-of-sale terminals at Target, Home Depot, and other major retailers, Visa, Mastercard and Discover[81] in March 2012 – and American Express[82] in June 2012 – announced their EMV migration plans for the United States.[83] Since the announcement, multiple banks and card issuers have announced cards with EMV chip-and-signature technology, including American Express, Bank of America, Citibank, Wells Fargo,[84] JPMorgan Chase, U.S. Bank, and several credit unions.

In 2010, a number of companies began issuing pre-paid debit cards that incorporate Chip and PIN and allow Americans to load cash as euros or pound sterling.[85][1] United Nations Federal Credit Union was the first United States issuer to offer Chip and PIN credit cards.[86] In May 2010, a press release from Gemalto (a global EMV card producer) indicated that United Nations Federal Credit Union in New York would become the first EMV card issuer in the United States, offering an EMV Visa credit card to its customers.[87] JPMorgan was the first major bank to introduce a card with EMV technology, namely its Palladium card, in mid-2012.[88]

As of April 2016, 70% of U.S. consumers had EMV cards and as of December 2016 roughly 50% of merchants were EMV compliant.[89][90] However, deployment has been slow and inconsistent across vendors. Even merchants with EMV hardware may not be able to process chip transactions due to software or compliance deficiencies.[91] Bloomberg has also cited issues with software deployment, including changes to audio prompts for Verifone machines which can take several months to release and deploy software out. Industry experts, however, expect more standardization in the United States for software deployment and standards. Visa and Mastercard have both implemented standards to speed up chip transactions with a goal of reducing the time for these to be under three seconds. These systems are labelled as Visa Quick Chip and Mastercard M/Chip Fast.[92]

  • American Express implemented liability shift for point of sale terminals on 1 October 2015.[93][promotional source?] For pay at the pump, at gas stations, the liability shift was 16 April 2021. This was extended from 1 October 2020 due to the COVID-19 pandemic.[94]
  • Discover implemented liability shift on 1 October 2015. For pay at the pump, at gas stations, the liability shift was 1 October 2020.[77]
  • Maestro implemented liability shift of 19 April 2013, for international cards used in the United States.[95]
  • Mastercard implemented liability shift for point of sale terminals on 1 October 2015.[93] For pay at the pump, at gas stations, the liability shift formally was on 1 October 2020.[96] For ATMs, the liability shift date was on 1 October 2016.[97][98]
  • Visa implemented liability shift for point of sale terminals on 1 October 2015. For pay at the pump, at gas stations, the liability shift formally was on 1 October 2020.[96][99] For ATMs, the liability shift date was on 1 October 2017.[70][1]

Notes

[edit]

See also

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia
from Grokipedia
EMV (originally standing for Europay, , and Visa) is a global for secure and , specifying the use of chips to authenticate cardholder transactions and replace vulnerable magnetic stripe technology with dynamic data generation for prevention. Developed in the 1990s by Europay, , and Visa to address rising in card-not-present and counterfeit attacks on magnetic stripes, the standard enables interoperable, chip-based payments across diverse payment ecosystems. The first EMV specifications were published in 1996 as the EMV ‘96 Integrated Circuit Card Application Specification, marking the formal introduction of chip technology for and . In 1999, EMVCo was established as an independent organization to oversee the development, maintenance, and certification of these specifications, ensuring worldwide compatibility and security. Today, EMVCo is equally owned by six major payment networks—[American Express](/page/American Express), , , , , and [Visa Inc.](/page/Visa Inc.)—which collaborate on technical advancements while maintaining equal governance. Over its 25-year history, EMV has expanded beyond basic chip authentication to encompass [contactless payments](/page/Contactless payments) (introduced in the early 2000s), EMV for e-commerce fraud reduction (2007), payment tokenization (2014), EMV QR Code Specifications for consumer-presented and merchant-presented modes in mobile wallets (2017), and contactless kernel standards for streamlined acceptance (2022). These evolutions support seamless transactions via cards, mobile devices, and emerging formats like electric vehicle charging. As of the end of 2024, the adoption of EMV technology had reached significant scale, with over 14.7 billion EMV chip cards in circulation globally, 72% of all issued payment cards EMV-enabled, and 96% of card-present transactions processed using EMV methods, substantially lowering fraud rates compared to legacy systems.

Introduction

Definition and Purpose

EMV is a global technical standard for secure payment processing using chip-based smart cards and acceptance terminals, originally developed jointly by Europay, , and Visa, and now managed by the EMVCo to promote worldwide . The standard defines the protocols for chip cards to communicate with [payment systems](/page/Payment system), ensuring consistent functionality across diverse devices and networks. The primary purpose of EMV is to replace vulnerable magnetic stripe cards with chips embedded in cards, enabling dynamic that generates unique transaction for each use rather than static information. This shift addresses key weaknesses in traditional cards by supporting cryptographic verification between the card and terminal, significantly reducing risks of and from lost or stolen cards. EMV delivers enhanced through on-chip cryptographic operations that validate card authenticity and authorize transactions without exposing sensitive , while also accommodating both contact (via physical insertion) and contactless (via proximity tapping) interfaces for versatile use cases. Additionally, its fosters compatibility across multiple schemes, allowing issuers, acquirers, and merchants to deploy uniform solutions globally without proprietary barriers. To ensure reliability, EMV certification is structured in three levels. Level 1 verifies the physical interface, including electrical, mechanical, and radio interfaces for contact and contactless interactions. Level 2 evaluates the , confirming that software implementations correctly execute EMV protocols for secure data exchange and . Level 3 validates the integration of the EMV-compliant payment acceptance terminal with its acceptance infrastructure to ensure end-to-end secure transaction processing.

Global Adoption and Impact

By 2025, the global adoption of EMV technology has reached near-universal levels in payment infrastructure, with over 97% of EMV-enabled worldwide supporting [contactless payments](/page/Contactless payments), an increase from 94% in 2024. This milestone reflects ongoing upgrades in terminal capabilities to accommodate faster, tap-and-go transactions, driven by consumer demand and regulatory pressures in major markets. As of 2025, over 14.7 billion EMV chip cards are in circulation globally. EMV chip transactions now account for approximately 96% of all card-present payments globally, underscoring the standard's dominance in securing in-person commerce. The EMV cards market has experienced steady expansion, valued at US$4.3 billion in 2024 and projected to reach US$6.3 billion by 2030, growing at a (CAGR) of 6.5%. This growth is fueled by the integration of contactless features and the rising need for secure solutions amid increasing digital transaction volumes. Furthermore, the migration to EMV has significantly reduced fraud, with reports indicating reductions of up to 87%, as the chip's dynamic thwarts card duplication attempts more effectively than magnetic stripe . Economically, EMV adoption has shifted fraud liability from issuers to non-compliant merchants, incentivizing widespread upgrades and reducing overall costs for financial institutions through lower fraud losses. This liability framework has encouraged merchants to invest in compatible systems, minimizing chargebacks and operational risks while promoting the broader shift to digital , including mobile wallets and contactless methods that enhance transaction efficiency. Issuers benefit from decreased exposure to claims, fostering a more stable ecosystem that supports global commerce growth.

History

Origins and Development

In the late and early , the proliferation of magnetic stripe cards facilitated a surge in payment fraud, including skimming and card creation, as the static data on the stripes proved easy to replicate and exploit. This vulnerability prompted major payment networks to seek more robust alternatives, leading Europay, , and Visa to form a collaborative in 1994 aimed at developing unified chip-based standards for secure transactions. The partnership yielded its initial technical output with the release of the EMV 3.0 specifications on June 30, 1996, which outlined protocols for cards in payment systems, emphasizing dynamic data generation to thwart . These specifications marked the foundational framework for embedding microchips in cards, enabling cryptographic between cards and terminals. To oversee ongoing maintenance and evolution, the founding companies established EMVCo in 1999 as an independent entity, initially owned by Europay, , and , dedicated to ensuring global and security enhancements. Early adoption trials demonstrated the potential of chip technology; in , pilots began in 1992, integrating chips into bank cards to address domestic fraud ahead of broader EMV alignment. Similarly, the launched EMV-based Chip and PIN trials in in May 2003, followed by a national rollout in October, significantly reducing counterfeit fraud in card-present environments.

Evolution of Standards

The evolution of EMV standards progressed significantly with the EMV Contactless Specifications for Payment Systems version 1.0, released in March 2004, which marked the introduction of capabilities for [contactless payments](/page/Contactless payments) through proximity payment systems, enabling faster transactions via NFC-enabled cards and terminals while maintaining chip-based security protocols. This advancement built on the core EMV framework to support seamless in-person payments, reducing reliance on magnetic stripes and fostering global interoperability for proximity-based interactions. By 2011, EMV version 4.3 further expanded the specifications to accommodate emerging mobile devices, incorporating provisions for integration in smartphones and laying foundational elements for tokenization by enhancing data protection mechanisms in application specifications. These updates emphasized backward compatibility while addressing the growing need for ecosystems, including initial support for dynamic data authentication in [contactless payments](/page/Contactless payments) scenarios. In 2019, EMVCo published the EMV Secure Remote Commerce (SRC) Specification version 1.0 for streamlined online checkouts. Enhancements to EMV (3DS) version 2.2, released in December 2018, improved frictionless authentication through risk-based assessments and device data sharing to bolster security. In 2024, EMVCo launched a reduced range approval process for Level 1 type approval, tailored for TapToMobile device integration, defining compliance levels with adjusted read-range requirements to facilitate broader of and enterprise smartphones as acceptors. Concurrently, the ISO/IEC 24760-3:2025 standard provided a framework for tokenized identity management, outlining practices for handling identity information in secure systems, including token lifecycle processes aligned with EMV tokenization principles. Looking ahead, EMVCo initiated development of the EMV TEST PCD-2 specification in 2025 to refine proximity coupling device testing for [contactless payments](/page/Contactless payments) interfaces, with a public comment period open until November 30, 2025, inviting industry input to ensure robust performance in evolving environments.

Technical Specifications

Chip Architecture and Components

The EMV chip is a microprocessor-based (IC) embedded in cards, designed to securely store and process transaction . It typically incorporates a (CPU), often an 8-bit or 16-bit processor, to execute instructions and manage operations. The chip includes various types: (ROM) for storing the permanent operating and fixed , electrically erasable programmable () for application and keys that can be updated, and (RAM) for temporary processing during transactions. Additionally, a dedicated cryptographic handles , decryption, and algorithms such as DES, 3DES, or RSA to ensure secure computations without exposing sensitive information. Physically, EMV chips support both contact and contactless interfaces to enable versatile payment methods. The contact interface adheres to standards, utilizing eight electrical contacts (C1 to C8) on the card's surface for communication with terminals: these include pins for (VCC), reset (RST), clock (CLK), ground (GND), data (I/O), and auxiliary functions like programming voltage (VPP) and auxiliary I/O. This wired connection allows for reliable data exchange at speeds up to 9600 initially, scalable to higher rates. In contrast, the [contactless payments](/page/Contactless payments) interface follows [ISO/IEC 14443](/page/ISO/IEC 14443) specifications, operating via (NFC) or (RFID) at 13.56 MHz, enabling wireless interactions within a short range (typically up to 10 cm) without physical insertion, using modulated electromagnetic fields for power and data transfer. Logically, the chip runs a card operating system (COS), which is a layer embedded in ROM that oversees file management, operations, and to support multiple applications on a single card. The file structure follows a hierarchical model defined in -4, featuring a master file (MF) at the root, dedicated files (DFs) for specific applications (e.g., or programs), and elementary files (EFs) containing elements like cardholder information or certificates. Each application is identified by a unique application identifier (), composed of a registered application provider identifier (RID) assigned by ISO and a application identifier extension (PIX) defined by the issuer, allowing the terminal to select and interact with the appropriate application during transactions. To ensure interoperability and reliability, EMV chips undergo Level 1 certification testing, which verifies compliance with electrical, mechanical, and basic communication protocols outlined in the EMV specifications. This includes assessments of contact interface integrity, signal timing, power consumption, and contactless , conducted by accredited laboratories to confirm the chip meets global standards before personalization and issuance.

Data Elements and Commands

In EMV transactions, communication between the card (ICC) and the terminal follows the Application Protocol Data Unit (APDU) format specified in -4, which structures exchanges as command-response pairs. A Command APDU (C-APDU) comprises a four-byte header consisting of the class byte (CLA), instruction byte (INS), parameter bytes (P1 and P2), an optional length field (Lc, length of command data) indicating the length, an optional field carrying input parameters, and an optional length field (Le) indicating the expected length of the response data. The corresponding Response APDU (R-APDU) includes an optional field with output results followed by two status bytes (SW1 and SW2), where the value 90 00 signifies successful command execution without errors, while other values such as 69 82 indicate security-related issues like failure. EMV defines several standardized C-APDUs for core operations, executed by the card's embedded to manage application selection, , and security processing. The SELECT command (INS = A4) identifies and activates a specific application using its Application Identifier (AID) as the data field, enabling the terminal to choose from multiple supported applications on the card. The READ RECORD command (INS = B2) retrieves records from elementary files (EFs) in the card's file structure, such as application-specific data, by specifying the file ID in P1/P2 and record number. The VERIFY command (INS = 20) authenticates the cardholder by comparing a provided PIN against the stored reference, with P1/P2 indicating the PIN format (e.g., plain or encrypted). Additionally, the GET PROCESSING OPTIONS command (INS = A8), unique to EMV, prompts the card to return processing parameters and initiate generation of an application , including a Processing Options Data Object List (PDOL) in the response to guide further terminal actions. Central to these commands are standardized data elements, encoded as tagged data objects using the TLV (Tag-Length-Value) format for . The Application Identifier (, tag 4F) is a variable-length identifier (5-16 bytes) that uniquely distinguishes payment applications, combining a Registered Application Provider Identifier (RID) from -5 and a Application Identifier Extension (PIX) for scheme-specific details, such as Visa's AID starting with A0 00 00 00 03 for its domestic application. The Application (tag 50), up to 16 characters, provides a human-readable name for the application (e.g., "VISA CREDIT") displayed on the terminal for user selection. Track 2 Equivalent (tag 57), a variable-length field mirroring magnetic stripe Track 2 per ISO/IEC 7813, encodes the Primary Account Number (PAN), expiry date, service code, and discretionary data, excluding sentinels and check digits, to support fallback compatibility. The Application (AC, tag 9F26 for type and 9F27 for 8-byte value) is a dynamic cryptographic output generated by the card, representing types like Authorization Request Cryptogram (ARQC) for online verification or Transaction Certificate (TC) for approval. EMV leverages specific cryptographic primitives to secure data elements and command responses, balancing legacy compatibility with modern strength. Symmetric encryption relies on the (DES) and its strengthened variant, (3DES) with two or three keys, for operations like PIN protection and session key derivation in earlier specifications. Asymmetric employs RSA (typically 1024-2048 bits) for issuer and ICC public key certificates, enabling offline through digital signatures. Since the 2010s, the (AES) with 128-256 bit keys has been integrated for enhanced symmetric operations, including data encryption during personalization and cryptogram generation, offering superior performance and security over 3DES while maintaining .

Transaction Flow

Contact Transactions

Initiation and Application Selection

The initiation of an EMV transaction occurs when the payment terminal detects an EMV-compliant chip card. In contact-based transactions, the card is inserted into the terminal's slot, prompting the terminal to issue a reset signal; the card then responds with the Answer to Reset (ATR), a sequence that conveys the card's supported protocols, historical bytes indicating compliance levels, and initial interface parameters such as baud rate and parity. This ATR exchange establishes the basic communication link between the terminal and the card (ICC), adhering to standards for electrical and protocol specifications. Once the card is detected, the application selection phase identifies a mutually supported payment application. The terminal issues a SELECT command (APDU: CLA=00, INS=A4, P1=04, P2=00, Lc, <AID data>, Le=00) with the Application Identifier (AID) of the Payment System Environment for contact cards (AID: '1PAY.SYS.DDF01'), prompting the card to return a File Control Information (FCI) template listing available applications, their AIDs, and associated details like kernel identifiers; the card responds with status words SW1=90, SW2=00 for success, or error codes such as 6A82 (file not found) or 6985 (conditions of use not satisfied). The terminal then evaluates this list using partial AID matching—comparing the most significant bytes of its supported AIDs against the card's offerings—to select the highest-priority common application, issuing another SELECT command (APDU: CLA=00, INS=A4, P1=04, P2=00, Lc, <AID data>, Le=00) for the chosen AID, again expecting SW1=90, SW2=00 or appropriate error status words. This method allows multi-application cards to dynamically choose the appropriate scheme, such as Visa or , without predefined sequences. Following successful application selection, the terminal issues the GET PROCESSING OPTIONS (GPO) command (APDU: CLA=80, INS=A8, P1=00, P2=00, Lc, [PDOL data], Le=00) to initiate application processing within the card. The GPO command includes data elements from the card's Processing Data Object List (PDOL), if supported, to retrieve the Application Interchange Profile (AIP), which indicates the functions supported by the application, and the Application File Locator (AFL), which specifies the files and records to be read for transaction data; the expected response includes AIP and AFL data with SW1=90, SW2=00 for success, or 6985 for conditions of use not satisfied. If the card returns a status word of 6985 in response to the GPO command, it indicates that the conditions of use are not satisfied, often due to incomplete or incorrect PDOL data provided by the terminal, procedural errors, or the card being blocked, prompting the terminal to abort the transaction and potentially fallback to other methods. Visa supports an extended version of the GPO command, known as the Extended Get Processing Options (EGPO), which is used to support features like Integrated Data Storage. Integrated Data Storage (IDS) is a Visa-specific feature that enables the terminal to store certain data on the card during the transaction for use in subsequent interactions or services. It relies on the Data Exchange mechanism, where data is exchanged via APDU commands like the Extended Get Processing Options (EGPO), allowing the card to update its internal records securely. Subsequently, the terminal sends READ RECORD commands (APDU: CLA=00, INS=B2, P1=<SFI and record number>, P2=00, Le=00) based on the AFL to retrieve the necessary application elementary files (EFs) containing critical data elements like the primary account number (PAN) and application expiration date, with responses including the requested data and SW1=90, SW2=00 for success, or 6A83 (record not found) for errors. If no matching AID is identified during selection, the transaction may fallback to a magnetic stripe equivalent, where the terminal prompts the cardholder to swipe the card's magstripe track data for processing under legacy rules; however, EMV specifications and payment network guidelines strictly limit such fallbacks to technical failures, aiming to minimize non-chip usage for security reasons. Application selection employs Application Protocol Data Unit (APDU) commands standardized in EMV protocols to exchange data efficiently. The entire initiation and selection process is constrained by timing requirements to maintain transaction velocity, with card responses expected within up to 10 seconds for contact interfaces to prevent timeouts and ensure user-friendly performance.

Authentication and Verification

Authentication and verification in EMV transactions ensure the legitimacy of the chip card (ICC) and the integrity of transaction before proceeding to . This phase occurs after application selection and involves cryptographic mechanisms to prevent , such as counterfeiting or alteration, without requiring immediate online involvement. The primary methods rely on (PKI) and symmetric cryptography to validate the card's authenticity offline. Offline Data Authentication (ODA) is a foundational verification process that uses the card's to confirm its and the unaltered state of critical data elements, such as the primary account number (PAN) and expiry date. There are four variants of ODA, each offering increasing levels of . Static Data Authentication (SDA) employs a static RSA generated by the issuer on fixed card data; the terminal verifies this using the issuer's public key to ensure the data has not been modified since issuance, though it is susceptible to replay attacks if the card is cloned. Dynamic Data Authentication (DDA) enhances by generating a dynamic RSA on transaction-specific data, including a challenge from the terminal, using the card's unique private key; this proves possession of the genuine card as the cannot be reused. The terminal initiates DDA by sending an INTERNAL AUTHENTICATE command (APDU: 00 88 00 00 10 [Challenge] 00), with the card responding with the dynamic signature and SW1=90, SW2=00 for success, or 6982 (security status not satisfied) for errors. Visa and Mastercard support Fast Dynamic Data Authentication (fDDA), a variant similar to DDA but optimized for contactless transactions to enhance offline security in such environments. Combined Dynamic Data Authentication (CDA), the most advanced among RSA-based methods, integrates DDA with the transaction certificate in a single signed step, verifying both card and the card's approval decision for the transaction. eXtended Data Authentication (XDA) provides dynamic authentication similar to DDA but utilizes for enhanced efficiency and security, allowing smaller key sizes while maintaining strong cryptographic protection. EMV employs a certificate chain rooted in a trusted Certification Authority (CA) to enable secure key validation during ODA. The Issuer Public Key Certificate contains the issuer's public key and associated data, signed by the CA's private key; the terminal verifies this using the pre-loaded CA public key to recover the issuer public key. The Integrated Circuit Card (ICC) Public Key Certificate, signed by the issuer's private key, holds the card's public key and is validated using the recovered issuer public key, completing the chain and confirming the card's cryptographic credentials. This hierarchical PKI structure, based on RSA algorithms, ensures that only legitimate cards from certified issuers can pass authentication. Following ODA, the card generates an Application to further verify the transaction details. The Authorization Request (ARQC) is produced using a derived from the card's symmetric keys (typically 3DES or AES), combined with transaction data like the amount and unpredictable number; this is sent online to the for validation, proving the card's participation in the specific session. The terminal requests the ARQC by issuing the first GENERATE AC command (APDU: 80 AE 80 00 Lc [CDOL1 data] 00), with the response including the ARQC and SW1=90, SW2=00 for success, or 6985 for errors. The is uniquely generated per transaction from the card master key to prevent reuse and enhance .

Risk Management and Authorization

Terminal Risk Management (TRM) is a critical function performed by the payment terminal to mitigate fraud risks for the acquirer by evaluating transaction characteristics before proceeding further. This encompasses three primary : floor limit verification, which allows offline approval for transactions below a predefined threshold amount set by the acquirer; velocity checking, which monitors the frequency and volume of transactions from the same card within a specified time frame to identify potential ; and random transaction selection (RTS), a probabilistic mechanism that occasionally routes low-risk transactions online to ensure periodic oversight regardless of other parameters. These are configurable based on acquirer policies and are executed after application selection and before deeper analysis, helping to balance transaction speed with . Following TRM, Terminal Action Analysis (TAA) enables the terminal to assess overall transaction risk using parameters such as the transaction amount, cardholder verification results, and TRM outcomes, ultimately deciding whether to approve the transaction offline, decline it, or forward it for . If the indicates low —such as when the transaction falls within acceptable limits and no red flags are raised—the terminal may generate an offline approval by requesting a Transaction Certificate (TC) from the card via a GENERATE AC command specifying offline approval. The GENERATE AC command is used by the terminal to request the card to generate application cryptograms such as a Transaction Certificate (TC) for offline approval, an Authorization Request Cryptogram (ARQC) for online authorization, or an Application Authentication Cryptogram (AAC) for decline. An example of the APDU format for the first GENERATE AC command is 80 AE 80 00 Lc [CDOL1 data] 00, with responses including the appropriate cryptogram and SW1=90, SW2=00 for success. Conversely, higher-risk scenarios trigger an request, where the terminal prompts the card to produce an Authorization Request (ARQC), building on the cryptograms established during prior steps. This decision-making ensures that only suitable transactions proceed offline, reducing exposure to while maintaining efficiency. Card Action Analysis (CAA) complements terminal efforts by allowing the EMV chip to independently evaluate using its embedded issuer-defined models, which consider factors like cumulative transaction counters, offline limits, and local card . Based on this assessment, the card generates an appropriate application : a TC to signal offline approval if risks are deemed acceptable; an Application Authentication (AAC) to indicate an offline decline if thresholds are exceeded; or an ARQC to mandate online processing for further scrutiny. This card-centric layer provides an additional safeguard, enabling issuers to enforce personalized controls without relying solely on terminal logic. In the online authorization flow, when an ARQC is generated—either through TAA or CAA—the terminal packages it into an message along with transaction details and forwards the request to the acquirer, who relays it to the 's host for real-time validation. The authenticates the ARQC, verifies cardholder and legitimacy, and responds with approval or denial, ensuring dynamic risk evaluation for potentially suspicious transactions. This process integrates seamlessly with payment network protocols, enhancing overall system integrity.

Completion and Post-Processing

Following the phase, issues a second GENERATE AC command (APDU: 80 AE 40 00 Lc [CDOL2 data] 00 for TC request) to the card (ICC), incorporating the authorization response from the or acquirer if the transaction was processed online. This command prompts the card to generate either a Transaction Certificate (TC) to approve and finalize the transaction or an Application Authentication Cryptogram (AAC) to decline it, based on the combined results of the card's internal and the external authorization decision, with SW1=90, SW2=00 accompanying the cryptogram for success. The TC confirms that the card has validated the transaction details and is authorizing the payment, while the AAC indicates rejection due to factors such as exceeded limits or checks. After the card responds to the second GENERATE AC, the terminal may process any issuer scripts included in the authorization response. These scripts consist of a series of application (APDU) commands sent by the to modify card parameters, such as updating spending limits, blocking the card, or changing the PIN, without interrupting the transaction flow. Script processing occurs post-authentication to ensure the primary authorization completes first, and the card executes the commands sequentially, reporting the outcome via status words for each. If script execution fails, the terminal sets the 'Script processing failed after final GENERATE AC' bit in the Terminal Verification Results (Terminal Verification Results) to indicate the issue, though this does not reverse the transaction approval. Upon successful completion of the second GENERATE AC and any applicable script processing, the transaction concludes with the terminal generating a receipt for the cardholder, detailing key elements such as the amount, date, merchant information, and approval code, while also logging the full transaction data for acquirer and settlement. This logging captures cryptograms, tags, and verification results to support and , ensuring auditability across the payment ecosystem. Error handling in the completion phase relies on status words returned by the card in response to commands, providing diagnostic codes for issues like declines or partial authentications. For instance, a successful response uses status word '9000', while declines due to authorization failure return '6985' (conditions of use not satisfied) or '63Cx' for counter exceedance, prompting the terminal to abort and notify the user. The 6985 response, particularly in contexts like the GPO command, may arise from procedural errors such as incomplete data objects or unfulfilled processing conditions, leading to transaction termination.

Contactless Transactions

Architecture and Components

According to the EMV Contactless Specifications for Payment Systems Book A: Architecture and General Requirements, the contactless EMV system comprises key components including the terminal, the contactless reader, and the card, each with defined roles to ensure secure and efficient transaction processing. The terminal oversees the overall transaction flow, including application selection, risk management, authorization, and completion. The contactless reader, integrated into the terminal, facilitates proximity-based communication with the card using NFC at 13.56 MHz, handling card detection, anti-collision procedures, and data exchange as per [ISO/IEC 14443](/page/ISO/IEC 14443) standards. The card, known as the Proximity Integrated Circuit Card (PICC), provides dynamic data, performs cryptographic authentication, and generates application cryptograms to validate the transaction. Transaction outcomes, as outlined in Book A section 6, include approvals (successful completion with TC generation), declines (AAC generation due to failed checks), and referrals (ARQC for online issuer decision), determined collaboratively by these components' interactions at stages like entry point, kernel activation, and post-authorization processing; these outcomes correspond to UI messages such as '03' for approved (Card Read Successfully) or '01' for declined.

MSD vs. Full EMV Contactless Modes

[Contactless payments](/page/Contactless payments) can operate in two primary modes: Magnetic Stripe Data (MSD) mode and full EMV mode. MSD mode emulates the data transmission of a traditional magnetic stripe transaction, sending static card data such as the primary account number (PAN), expiration date, and service code without dynamic cryptographic processes or offline authentication, resulting in security levels comparable to legacy magstripe swipes and vulnerability to skimming, cloning, and replay attacks. The transaction flow in MSD mode typically includes the following steps: (1) the terminal initiates contactless communication via NFC and performs the anti-collision procedure according to [ISO/IEC 14443](/page/ISO/IEC 14443) to select and detect the card; (2) the payment application is selected, typically through the Payment System Environment (PPSE) using the SELECT command with AID '2PAY.SYS.DDF01'; (3) the terminal reads static card data equivalent to magnetic stripe Track 1 and Track 2, including the PAN, expiration date, service code, and other discretionary data; and (4) the terminal sends an authorization request to the issuer for online verification, without any offline cryptographic authentication. In contrast, full EMV [contactless payments](/page/Contactless payments) leverages the chip's capabilities for dynamic data generation, application selection, and cryptographic authentication methods like Static Data Authentication (SDA), Dynamic Data Authentication (DDA), or Combined Dynamic Data Authentication (CDA), enabling offline verification of card authenticity and transaction integrity for superior fraud prevention. MSD mode facilitates compatibility with legacy terminals and systems that lack full EMV contactless support, allowing for faster initial adoption of [contactless payments](/page/Contactless payments) by bypassing complex chip protocols. However, due to its limited security, payment networks and issuers are actively phasing out MSD; for instance, as of 2018, issuers were encouraged to prioritize EMV contactless issuance, and by 2020, many regions mandated full EMV for contactless to ensure liability shifts and enhanced protections.

Initiation and Application Selection

For [contactless payments](/page/Contactless payments), detection relies on proximity coupling devices (PCD) in the terminal energizing the card's proximity integrated circuit card (PICC) via a 13.56 MHz radio frequency field, as defined in [ISO/IEC 14443](/page/ISO/IEC 14443). The terminal performs an anti-collision procedure—a binary tree search algorithm—to resolve conflicts if multiple cards are present, uniquely identifying and selecting one PICC before eliciting an initial response similar to the ATR, including protocol and historical information. This process ensures reliable card activation without physical contact, supporting faster transaction starts typical of (NFC) environments. Once the card is detected, the application selection phase identifies a mutually supported payment application. The terminal issues a SELECT command (APDU: CLA=00, INS=A4, P1=04, P2=00, Lc, <AID data>, Le=00) with the Application Identifier () of the Proximity Payment System Environment (PPSE) for contactless cards (AID: '2PAY.SYS.DDF01'), prompting the card to return a File Control Information (FCI) template listing available applications, their AIDs, and associated details like kernel identifiers, with SW1=90, SW2=00 for success or error codes like 6A82. The terminal then evaluates this list using partial AID matching—comparing the most significant bytes of its supported AIDs against the card's offerings—to select the highest-priority common application, issuing another SELECT command (APDU: CLA=00, INS=A4, P1=04, P2=00, Lc, <AID data>, Le=00) for the chosen AID. This method allows multi-application cards to dynamically choose the appropriate scheme, such as Visa or , without predefined sequences. Following successful application selection, the terminal issues the GET PROCESSING OPTIONS (GPO) command (APDU: CLA=80, INS=A8, P1=00, P2=00, Lc, [PDOL data], Le=00) to initiate application processing within the card. The GPO command includes data elements from the card's Processing Data Object List (PDOL), if supported, to retrieve the Application Interchange Profile (AIP), which indicates the functions supported by the application, and the Application File Locator (AFL), which specifies the files and records to be read for transaction data, expecting SW1=90, SW2=00 or 6985. If the card returns a status word of 6985 in response to the GPO command, it indicates that the conditions of use are not satisfied, often due to incomplete or incorrect PDOL data provided by the terminal, procedural errors, or the card being blocked, prompting the terminal to abort the transaction and potentially fallback to other methods. Subsequently, the terminal sends READ RECORD commands (APDU: CLA=00, INS=B2, P1=<SFI and record number>, P2=00, Le=00) based on the AFL to retrieve the necessary application elementary files (EFs) containing critical data elements like the primary account number (PAN) and application expiration date, with SW1=90, SW2=00 or 6A83 for errors. If no matching AID is identified during selection, the transaction may fallback to a magnetic stripe equivalent, where the terminal prompts the cardholder to swipe the card's magstripe track data for processing under legacy rules; however, EMV specifications and payment network guidelines strictly limit such fallbacks to technical failures, aiming to minimize non-chip usage for security reasons. Application selection employs Application Protocol Data Unit (APDU) commands standardized in EMV protocols to exchange data efficiently. The entire initiation and selection process is constrained by timing requirements to maintain transaction velocity, with card responses expected within hundreds of milliseconds for contactless (typically 300-700 ms total) to prevent timeouts and ensure user-friendly performance.

Entry Point

In EMV [contactless payments](/page/Contactless payments), the Entry Point, as defined in the EMV Contactless Book B Entry Point Specification, serves as the foundational software component that manages the initial transaction pre-processing, protocol activation, and application selection. Pre-processing involves the initial setup and data preparation before card interaction, including configuring terminal parameters, setting initial indicators, and preparing data elements such as transaction amounts and terminal capabilities. Protocol activation initiates communication between the terminal and the card, encompassing detection of the card's presence, anti-collision procedures to resolve conflicts if multiple cards are detected, and establishing a secure communication channel. Application selection then occurs, where the terminal selects the appropriate payment application on the card based on supported protocols and preferred applications, leading to the activation of the corresponding kernel for transaction processing. Successful outcomes at each stage enable progression: pre-processing success prepares the environment for interaction; protocol activation success facilitates data exchange; and application selection success determines kernel activation, allowing the transaction to proceed to offline data authentication and risk management. If any stage fails, the transaction is typically aborted or redirected to an error state—for instance, failure in protocol activation results in no communication being established and the transaction terminating; failure in application selection means no suitable kernel is activated, preventing further processing and potentially directing the terminal to an alternative entry point or error handling routine. It supports a multi-kernel architecture by facilitating the interaction between the terminal's contactless reader and the card, ensuring efficient handling of the transaction flow from the first presentment onward. This includes coordinating data exchange for generating an Authorization Request Cryptogram (ARQC) during the first presentment and enabling the second presentment for Transaction Certificate (TC) verification without repeating sensitive operations like balance decrements or counter updates.

First and Second Presentment

Building on the Entry Point processes detailed above, the process often distinguishes between a first presentment and a second presentment of the card, particularly in scenarios requiring online authorization. The first presentment occurs when the card is initially tapped to the terminal, initiating the transaction through detection, anti-collision, application selection, offline data authentication, risk management, and the generation of an ARQC if online processing is needed. This step allows the terminal to gather necessary data and send it to the issuer for approval. The second presentment involves tapping the card again after the issuer's response is received, enabling the card to verify the authorization outcome and generate a TC to complete and approve the transaction. During the second presentment, the card does not repeat actions such as decrementing balances or updating transaction counters to avoid duplicate processing or double charging. This dual-presentment mechanism, detailed in specifications like EMV Book C-2 for Mastercard and EMV Book C-3 Kernel 3 Specification version 2.11, section 2.3.1, supports secure handling of online transactions in contactless environments while preserving transaction speed and preventing fraud from replay or cloning attacks.

Authentication and Verification

Authentication and verification in EMV transactions ensure the legitimacy of the chip card (ICC) and the integrity of transaction before proceeding to . This phase occurs after application selection and involves cryptographic mechanisms to prevent , such as counterfeiting or alteration, without requiring immediate online involvement. The primary methods rely on (PKI) and symmetric to validate the card's authenticity offline. Offline Data Authentication (ODA) is a foundational verification process that uses the card's to confirm its and the unaltered state of critical data elements, such as the primary account number (PAN) and expiry date. There are four variants of ODA, each offering increasing levels of . Static Data Authentication (SDA) employs a static RSA generated by the issuer on fixed card data; the terminal verifies this using the issuer's public key to ensure the data has not been modified since issuance, though it is susceptible to replay attacks if the card is cloned. Dynamic Data Authentication (DDA) enhances by generating a dynamic RSA on transaction-specific data, including a challenge from the terminal, using the card's unique private key; this proves possession of the genuine card as the cannot be reused. The terminal initiates DDA by sending an INTERNAL AUTHENTICATE command (APDU: 00 88 00 00 10 [Challenge] 00), with SW1=90, SW2=00 or 6982. Combined Dynamic Data Authentication (CDA), the most advanced among RSA-based methods, integrates DDA with the transaction certificate in a single signed step, verifying both card and the card's approval decision for the transaction. eXtended Data Authentication (XDA) provides dynamic authentication similar to DDA but utilizes elliptic curve cryptography (ECC) for enhanced efficiency and security, allowing smaller key sizes while maintaining strong cryptographic protection. EMV employs a certificate chain rooted in a trusted Certification Authority (CA) to enable secure key validation during ODA. The Issuer Public Key Certificate contains the issuer's public key and associated data, signed by the CA's private key; the terminal verifies this using the pre-loaded CA public key to recover the issuer public key. The Integrated Circuit Card (ICC) Public Key Certificate, signed by the issuer's private key, holds the card's public key and is validated using the recovered issuer public key, completing the chain and confirming the card's cryptographic credentials. This hierarchical PKI structure, based on RSA algorithms, ensures that only legitimate cards from certified issuers can pass authentication. Following ODA, the card generates an Application to further verify the transaction details. The Authorization Request (ARQC) is produced using a derived from the card's symmetric keys (typically 3DES or AES), combined with transaction data like the amount and unpredictable number; this is sent online to the for validation, proving the card's participation in the specific session. The terminal requests the ARQC by issuing the first GENERATE AC command (APDU: 80 AE 80 00 Lc [CDOL1 data] 00), with SW1=90, SW2=00. The is uniquely generated per transaction from the card master key to prevent reuse and enhance . In [contactless payments](/page/Contactless payments), and verification prioritize speed while maintaining , often using lower transaction thresholds to bypass certain checks. Contactless interfaces comply with [ISO/IEC 14443](/page/ISO/IEC 14443) standards, employing Type 3 () or Type 4 (ISO 14443-compliant) proximity card (PICC) tags for rapid data exchange. For low-value payments below scheme-defined limits (e.g., $100 for Visa and in the United States (as of 2025)), ODA is performed, potentially using a simplified method such as SDA, though DDA or CDA remains supported for higher-risk scenarios. These limits include the Cardholder Verification Method (CVM) limit, which determines the transaction amount above which cardholder verification (e.g., PIN entry) is required, and the contactless floor limit, which sets the threshold for offline transaction approvals. In the U.S., the CVM limit is typically $100, and Visa mandates a "Zero No CVM" policy for EMV terminals to enhance security by requiring online authorization for transactions without CVM when appropriate. These adaptations balance convenience with fraud prevention in high-volume environments like transit or retail.

Risk Management and Authorization

Terminal Risk Management (TRM) is a critical function performed by the payment terminal to mitigate fraud risks for the acquirer by evaluating transaction characteristics before proceeding further. This encompasses three primary : floor limit verification, which allows offline approval for transactions below a predefined threshold amount set by the acquirer; velocity checking, which monitors the frequency and volume of transactions from the same card within a specified time frame to identify potential ; and random transaction selection (RTS), a probabilistic mechanism that occasionally routes low-risk transactions online to ensure periodic oversight regardless of other parameters. These are configurable based on acquirer policies and are executed after application selection and before deeper analysis, helping to balance transaction speed with . In [contactless payments](/page/Contactless payments), these checks are adapted for faster processing, often with scheme-specific floor limits for low-value taps. Specifically, the Reader Contactless Floor Limit defines the maximum amount for offline contactless transactions, while the Reader CVM Limit specifies the threshold above which cardholder verification is mandatory. For example, in the U.S., Mastercard sets the CVM limit such that transactions below it can proceed offline without verification, subject to risk parameters, and floor limits are often set to zero for full EMV compliance to force online authorization where needed. Following TRM, Terminal Action Analysis (TAA) enables the terminal to assess overall transaction risk using parameters such as the transaction amount, cardholder verification results, and TRM outcomes, ultimately deciding whether to approve the transaction offline, decline it, or forward it for . If the indicates low —such as when the transaction falls within acceptable limits and no red flags are raised—the terminal may generate an offline approval by requesting a Transaction Certificate (TC) from the card via a GENERATE AC command specifying offline approval. Conversely, higher-risk scenarios trigger an request, where the terminal prompts the card to produce an Authorization Request (ARQC), building on the cryptograms established during prior steps. This decision-making ensures that only suitable transactions proceed offline, reducing exposure to while maintaining efficiency. Contactless flows prioritize quick offline approvals for low-value transactions to support speed, guided by CVM and floor limits to determine verification and approval paths. Card Action Analysis (CAA) complements terminal efforts by allowing the EMV chip to independently evaluate using its embedded issuer-defined models, which consider factors like cumulative transaction counters, offline limits, and local card . Based on this assessment, the card generates an appropriate application : a TC to signal offline approval if risks are deemed acceptable; an Application Authentication (AAC) to indicate an offline decline if thresholds are exceeded; or an ARQC to mandate online processing for further scrutiny. This card-centric layer provides an additional safeguard, enabling issuers to enforce personalized controls without relying solely on terminal logic. In the online authorization flow, when an ARQC is generated—either through TAA or CAA—the terminal packages it into an message along with transaction details and forwards the request to the acquirer, who relays it to the 's host for real-time validation. The authenticates the ARQC, verifies cardholder and legitimacy, and responds with approval or denial, ensuring dynamic risk evaluation for potentially suspicious transactions. This process integrates seamlessly with payment network protocols, enhancing overall system integrity.

Completion and Post-Processing

Following the phase, issues a second GENERATE AC command to the card (ICC), incorporating the authorization response from the or acquirer if the transaction was processed online. This command prompts the card to generate either a Transaction Certificate (TC) to approve and finalize the transaction or an Application Authentication Cryptogram (AAC) to decline it, based on the combined results of the card's internal and the external authorization decision, with SW1=90, SW2=00 for success; the outcome determines the UI message per Book A, such as '03' for approved or '01' for declined. The TC confirms that the card has validated the transaction details and is authorizing the payment, while the AAC indicates rejection due to factors such as exceeded limits or checks. After the card responds to the second GENERATE AC, the terminal may process any issuer scripts included in the authorization response. These scripts consist of a series of application (APDU) commands sent by the to modify card parameters, such as updating spending limits, blocking the card, or changing the PIN, without interrupting the transaction flow. Script processing occurs post-authentication to ensure the primary authorization completes first, and the card executes the commands sequentially, reporting the outcome via status words for each. If script execution fails, the terminal sets the 'Script processing failed after final GENERATE AC' bit in the Terminal Verification Results () to indicate the issue, though this does not reverse the transaction approval. Upon successful completion of the second GENERATE AC and any applicable script processing, the transaction concludes with the terminal generating a receipt for the cardholder, detailing key elements such as the amount, date, merchant information, and approval code, while also logging the full transaction data for acquirer and settlement. This logging captures cryptograms, tags, and verification results to support and , ensuring auditability across the payment ecosystem. In contactless scenarios, the process aligns similarly but may abbreviate certain steps for speed. Error handling in the completion phase relies on status words returned by the card in response to commands, providing diagnostic codes for issues like declines or partial authentications. For instance, a successful response uses status word '9000', while declines due to authorization failure return '6985' (conditions of use not satisfied) or '63Cx' for counter exceedance, prompting the terminal to abort and notify the user. The 6985 response, particularly in contexts like the GPO command, may arise from procedural errors such as incomplete data objects or unfulfilled processing conditions, leading to transaction termination. In [contactless payments](/page/Contactless payments), partial authentication (e.g., via AAC without full online approval) may trigger specific handling, such as falling back to online processing or declining if thresholds are unmet, with the terminal updating the TVR accordingly and displaying appropriate UI outcomes per Book A, such as referral for online decisions.

Contactless Kernel-Specific Transaction Flows

EMV [contactless payments](/page/Contactless payments) utilize scheme-specific kernels, each defining tailored processes for application selection, data authentication, and authorization to accommodate network requirements while ensuring interoperability and security. These kernels are outlined in the EMV Contactless Specifications Books C-2 through C-8 and generally employ standard EMV status words (e.g., 9000 for success) for core commands, with scheme-specific behaviors in command support and outcomes. Regarding contactless magnetic stripe emulation (MSD mode) for backward compatibility with legacy systems, support is provided by the C-2 (Mastercard), C-3 (Visa), and C-4 (American Express) kernels, while the C-5 (JCB), C-6 (Discover), C-7 (UnionPay), and C-8 (Unified) kernels primarily utilize full EMV modes without MSD support.
C-2 Kernel (Mastercard)
The C-2 kernel supports Mastercard contactless transactions, emphasizing fast processing for low-value payments. Application selection uses the PPSE with Mastercard-specific AIDs. Authentication typically employs CDA or DDA for dynamic verification, with authorization favoring online ARQC generation unless below floor limits. Unique features include velocity checks and specific CVM rules, such as no CVM for transactions under defined thresholds. Additionally, it incorporates the relay resistance protocol command, which counters relay attacks by using timed C-APDU exchanges (EXCHANGE RELAY) if supported by both the card and reader, expecting standard status words. Another feature is the COMPUTE CRYPTOGRAPHIC CHECKSUM command, which generates a CVC3 cryptogram equivalent to Track 2 data for verifying contactless transactions emulating magnetic stripe mode, with SW1=90, SW2=00 for success. Outcomes align with Book A UI messages, such as '03' for approved.
C-3 Kernel (Visa)
The C-3 kernel is designed for Visa payWave transactions. It involves PPSE selection followed by Visa AID matching. Authentication supports SDA, DDA, and CDA, with quick Visa Secure Domestic Contactless (qVSDC) for simplified low-risk flows. Authorization often requires online processing, with distinct floor and CVM limits to balance speed and security. The kernel also supports optional issuer update processing through issuer scripts, utilizing EMV tags 71 and 72 for script templates, which are processed via the EXTERNAL AUTHENTICATE command following the GENERATE AC command, using standard status words like 9000. Outcomes include Book A UI such as '01' for declined in high-risk cases.
C-4 Kernel (American Express)
The C-4 kernel facilitates American Express contactless payments via SafeKey. The flow includes PPSE-based selection and Amex-specific AIDs. It prioritizes CDA for authentication and integrates with online authorization for most transactions, featuring unique risk parameters tailored to Amex's global network, with standard EMV status words and Book A UI outcomes.
C-5 Kernel (JCB)
The C-5 kernel handles JCB contactless transactions. Application selection follows standard PPSE procedures with JCB AIDs. Authentication uses DDA or CDA, with authorization flows adapted for JCB's international requirements, including specific offline approval thresholds, employing standard status words.
C-6 Kernel (Discover)
The C-6 kernel supports Discover and Diners Club contactless payments. It employs PPSE selection and supports dynamic authentication methods. Authorization emphasizes online verification, with flows differing in data elements and CVM handling compared to other kernels, using standard responses and UI outcomes.
C-7 Kernel (UnionPay)
The C-7 kernel is for UnionPay QuickPass transactions, particularly prominent in Asia. Selection uses PPSE with UnionPay AIDs, authentication relies on CDA, and authorization includes provisions for high-volume offline approvals suitable for transit scenarios, with standard status words.
C-8 Kernel (Unified)
Introduced in 2022, the C-8 unified kernel simplifies implementation by supporting multiple schemes (Visa, Mastercard, Amex, Discover, JCB, UnionPay) within a single framework. Transaction flows standardize application selection via a common PPSE, with flexible authentication (e.g., advanced ECC-based methods) and authorization paths that adapt to scheme-specific rules, reducing terminal complexity while enhancing future-proofing; it uses standard EMV status words across schemes.

Security Features

Offline Data Authentication

Offline Data Authentication (ODA) is a cryptographic mechanism in EMV standards that enables terminals to verify the authenticity of a chip card without real-time communication with the , relying on (PKI) to prevent counterfeiting and tampering. This process uses digital signatures generated during card personalization and verified using certificates in a certification , starting from a root certification authority down to the issuer's public key. ODA supports four primary methods—Static Data Authentication (SDA), Dynamic Data Authentication (DDA), Combined Data Authentication (CDA), and eXtended Data Authentication (XDA)—each offering varying levels of security against cloning and modification attacks. Static Data Authentication (SDA) is the simplest form of ODA, where the card provides static application data, such as the Track 2 Equivalent Data, signed by the issuer's private key during card issuance. The terminal verifies this Signed Static Data (SSD) using the issuer's public key, recovered from the Issuer Public Key Certificate stored on the card, confirming that the data has not been altered since personalization. However, SDA is vulnerable to cloning because the signed data remains unchanged across transactions, allowing an attacker to copy the chip contents and produce identical counterfeit cards that pass verification. Extended Static Data Authentication (Extended SDA) is an enhancement to SDA introduced in EMV Kernel 8 for contactless payments, allowing the inclusion of additional data objects in the authenticated static data via the Extended SDA Tag List (tag 9F81). This improves flexibility in data management while maintaining the static nature of SDA. Dynamic Data Authentication (DDA) enhances security by generating a transaction-specific signature, proving the card's possession of its private key without revealing it. Upon receiving an unpredictable number from the terminal, the card computes a digital signature over dynamic data—including the unpredictable number, transaction data, and card-specific elements—using its internal private key and provides the Signed Dynamic Application Data (SDAD). The terminal verifies this signature with the card's public key, obtained from the card's public key certificate, ensuring the card is genuine and not a static copy. DDA requires the card to perform RSA computations internally, making it more resource-intensive but resistant to cloning attacks that plague SDA. Combined Authentication (CDA) builds on DDA for scenarios like contactless transactions, integrating the dynamic with the card's application to provide a unified proof of authenticity and transaction validity. In CDA, the SDAD is computed over a combination of the unpredictable number, card issue , the dynamic (e.g., Application Request or ARQC), and a hash of transaction , allowing offline verification of both card legitimacy and integrity. This method supports key recovery, where the terminal recovers and validates the signed elements from the SDAD against expected formats and values, such as those defined in EMV , to ensure no tampering occurred. CDA is particularly suited for low-value, high-speed transactions, as it minimizes the need for separate authentication steps while maintaining dynamic protection. eXtended Data Authentication (XDA) is an advanced dynamic authentication method that uses elliptic curve cryptography (ECC) to provide enhanced efficiency and security with smaller key sizes, building on DDA principles for modern chip implementations. In XDA, the card generates a transaction-specific signature over dynamic data using its ECC-based private key, which the terminal verifies with the corresponding public key certificate, offering resistance to cloning attacks while reducing computational overhead compared to RSA-based DDA. This method supports offline verification similar to other ODA variants and is designed for improved performance in resource-constrained environments. Within the broader EMV transaction flow, ODA serves as an initial card verification step to establish trust before proceeding to risk management or authorization.

Cardholder Verification Methods

Cardholder verification methods (CVMs) in EMV transactions serve to authenticate the legitimate cardholder, reducing the risk of unauthorized use after the card itself has been authenticated. The card's chip contains a CVM List (tag 8E), a variable-length data object that defines a prioritized sequence of verification methods supported by the application, including applicable conditions (e.g., transaction amount, terminal type) and actions upon success or failure (e.g., try next method or fail the transaction). The terminal evaluates the list sequentially during the transaction flow, selecting the first method that matches the current context, and records the outcome in the CVM Results (tag 9F34) for inclusion in authorization messages. This flexible structure allows issuers to tailor verification based on risk, supporting combinations of methods rather than a single mandatory approach. The EMV specifications define up to seven core CVM types, encompassing variations of PIN, signature, and no verification, which can be configured in the CVM List with specific conditions like floor limits or terminal capabilities. Each entry in the list consists of a three-byte CV Rule: the first byte is the CVM Code identifying the method (e.g., 1F for PIN by ICC, where the PIN is transmitted in plaintext to the card for verification; 1E for enciphered offline PIN, where the PIN is verified by the card chip without issuer involvement; 1D for enciphered PIN, where the PIN is verified by the issuer through an online connection; 5E for signature, and 00 for no CVM), the second byte specifies conditions, and the third byte defines the action on failure. If no method succeeds, the transaction may be declined unless a is allowed. Chip and PIN Chip and PIN relies on a entered by the cardholder at the terminal for verification, either offline or online, making it a primary method for higher-security transactions. In offline PIN (CVM Code 1E), the terminal enciphers the entered PIN into a PIN block using the card's public key, recovered from the certificates during offline data authentication, then sends it to the card via the VERIFY command (CLA=00, INS=20) for comparison against the stored PIN. The card decrypts and checks the PIN, updating the PIN Try Counter (tag 9F17) if incorrect and potentially locking after three failed attempts; success allows the card to proceed with generating an application request cryptogram. This method is preferred in , where EMV chip-and-PIN rollout since the early has significantly lowered fraud rates compared to magnetic stripe systems. For online PIN (CVM Code 1D), the enciphered PIN block is forwarded to the during for remote verification, often required for amounts exceeding offline thresholds. PIN (CVM Code 1F) is a less secure variant where the PIN is sent unenciphered to the card, rarely used due to risks. Chip and Signature Chip and signature uses a dynamic data from the chip combined with the cardholder providing a handwritten on the receipt, which the visually compares to the card's signature panel. The CVM Code is 5E, typically applied when lacks PIN capabilities or for conditions like attended terminals and amounts below a limit, serving as a fallback in the CVM List. Upon success, the retains the signed as proof; failure leads to the next method or transaction decline. This approach is common , where EMV adoption has favored over PIN to align with existing practices and reduce costs. Variants in the CVM List may pair with prior PIN attempts (e.g., offline PIN followed by if PIN fails), balancing and . No CVM and Biometrics No CVM (CVM Code 00) applies to low-risk scenarios, such as transactions below the terminal's floor limit or contactless payments under defined thresholds (e.g., $50 in many regions), where chip authentication alone suffices without further cardholder proof. In contactless EMV, this is often the default for small amounts, with conditions like "unattended terminal not allowed" ensuring applicability. For enhanced security in no-CVM cases, especially contactless, Combined DDA/AC Generation (CDCVM) flags may be used to require additional dynamic checks, though this is more relevant to device-based implementations. , such as or iris scans, are not core CVM types in standard EMV but can be integrated as issuer-specific extensions or via Consumer Device CVM (CDCVM) in mobile or biometric-enabled cards, where the device performs verification before emulating the card. EMVCo provides security requirements for such device-based methods to ensure consistency with traditional CVMs.

Card-Not-Present Transactions

Challenges for Online and Remote Payments

EMV technology, designed primarily for physical card interactions, encounters significant limitations in non-face-to-face transactions such as , phone orders, and mail orders, where the chip's dynamic cannot be utilized. In these card-not-present (CNP) scenarios, payments rely on static data like the card verification value (CVV), which remains unchanged across transactions and is easily compromised in data breaches, exposing sensitive information without the protective cryptographic exchanges of chip-based verification. This incompatibility shifts fraudsters toward remote channels, as the standard EMV transaction flow—initiated by physical card insertion or tap—cannot occur without the card's presence. CNP transactions heighten risks of account takeover, where attackers use stolen credentials to make unauthorized purchases, and friendly fraud, in which legitimate cardholders dispute valid charges to receive refunds while retaining goods. These vulnerabilities contributed to CNP fraud rising significantly in the years leading up to widespread adoption, driven by the ease of exploiting static data in expanding online commerce. Prior to the 2010s, online and remote payments predominantly depended on magnetic stripe data, which was susceptible to skimming and , resulting in elevated rates as merchants absorbed losses from unverified transactions. This reliance amplified in CNP environments, as stripe data provided no real-time validation, leading to billions in disputed charges before EMV's broader implementation shifted protections to in-person use cases. As of 2024, CNP fraud accounted for the majority of total card fraud losses globally, representing around 70% in the UK, 74% in the , and around 80% in .

Solutions like EMV 3-D Secure and Secure Remote Commerce

EMV (3DS) is a protocol developed by EMVCo to enable risk-based for card-not-present (CNP) transactions, reducing fraud in while minimizing user friction. It facilitates secure online payments by allowing issuers to assess transaction risk using data shared from merchants, card networks, and devices, often resulting in seamless without additional input. The protocol supports dynamic methods, including such as or recognition and passkeys, integrated via the 3DS SDK on devices. Version 2.2 of EMV 3DS, released in December 2018, introduced enhancements for frictionless flow, where low-risk transactions proceed without challenging the cardholder, thereby improving conversion rates and user experience. This version optimizes exemptions under regulations like PSD2 in Europe by incorporating advanced risk modeling and device-specific data collection, such as operating system details and behavioral signals. EMV 3DS 2.2 also enables biometric verification within the merchant's app or website, supporting two-factor authentication without redirecting users to external pages, which addresses previous challenges in remote payment verification. By 2024, the global 3D Secure payment authentication market had reached approximately USD 3.95 billion, reflecting widespread integration in e-commerce platforms driven by regulatory mandates and fraud prevention needs. In 2025, EMVCo updated the EMV 3DS white paper to help banks, solution providers, and merchants optimize the EMV 3DS payment authentication experience. Merchant Initiated Transactions (MITs), also referred to as 3-D Secure Requestor Initiated (3RI) transactions, are a type of CNP transaction where the merchant initiates the payment without active cardholder involvement, based on prior agreements such as recurring subscriptions, installments, or unscheduled events like reauthorization for out-of-stock items. Within the EMV ecosystem, MITs leverage EMV 3-D Secure protocols to perform low-friction authentication using previously registered cardholder credentials, thereby mitigating fraud risks in remote commerce while ensuring compliance with standards for secure processing. This integration allows merchants to process payments efficiently, reducing chargebacks and supporting seamless experiences in scenarios like subscription services. Secure Remote Commerce (SRC), specified by EMVCo, provides a standardized framework for token-based remote payments, streamlining checkouts through services like Click to Pay. Initially released in , the specification received key updates in 2021 to enhance and support for digital wallets, allowing consumers to store payment credentials securely and complete transactions with a single click across participating merchants. SRC integrates with EMV payment tokenization by using surrogate values in place of sensitive card details during transmission, reducing the risk of data interception in non-face-to-face scenarios. In EMV ecosystems, tokenization replaces the primary account number (PAN) with a unique, limited-use token, such as a Device Account Number (DAN) in mobile wallets like , to limit exposure of sensitive data. DANs, which are provisioned to specific devices, ensure that even if intercepted, the token cannot be repurposed for unauthorized use without additional validation. This approach aligns with PCI DSS requirements by scoping out systems handling from full cardholder data compliance, thereby lowering operational risks and audit burdens for merchants and processors. SRC leverages these to enable secure, wallet-integrated payments, with initial implementations and pilots emerging in high-growth regions like to support expanding digital commerce.

Vulnerabilities and Mitigations

Historical Attacks and Exploits

In 2010, researchers demonstrated a on EMV Chip and PIN systems using hidden hardware to disable PIN verification on stolen cards. This exploit involved inserting a thin device, akin to a shim, between the card's chip and the terminal's reader to intercept communications. The hardware suppressed the PIN Verify command sent from the terminal to the card, responding instead with a success code (0x9000) to convince the terminal that verification had succeeded, thereby allowing fraudulent transactions without the correct PIN. The attack was prototyped with affordable components like an FPGA board and could be miniaturized to evade detection, exploiting the protocol's lack of strong between card and terminal. The following year, in 2011, a CVM downgrade attack was revealed that enabled PIN harvesting by manipulating the Cardholder Verification Method (CVM) list during skimming. Attackers used an EMV skimmer to intercept and modify the CVM list (tag 8E) returned by the card, downgrading it to prioritize "plaintext PIN verification performed by the ICC" (code 01 or 41) over secure options like online PIN or signature. This forced the terminal to send the entered PIN in cleartext to the skimmer, which harvested it while simulating successful verification to the card; action codes were also altered to avoid offline declines and ensure online authorization. The exploit targeted Static and Dynamic Data Authentication (SDA/DDA) cards, common at the time, and invalidated claims of PIN protection since logs could not distinguish tampered verifications. EMV's no-CVM transactions for low-value purchases provided another PIN vector, as terminals below a merchant-set threshold (e.g., $50–$100 in the or €25–€50 in , varying by network and region as of ) required no cardholder verification, allowing stolen cards to be used without PIN entry. This feature, intended for speed, exposed users to shoulder-surfing—where observers visually capture PINs during higher-value uses—or on point-of-sale devices that logged keystrokes for later exploitation. Such bypasses compounded risks, as a single observed PIN could enable unlimited on the same card. Magnetic stripe cloning persisted as a pre-EMV fallback exploit, where harvested track from skimmers could be encoded onto blank stripe cards for use on non-upgraded terminals. During EMV migration, many systems defaulted to magstripe mode if chip reading failed, even on chip-enabled cards, allowing cloned to authorize transactions without chip . This backwards-compatibility flaw enabled widespread until full EMV adoption shifted liability to non-compliant merchants.

Modern Vulnerabilities and Countermeasures

In recent years, contactless EMV transactions have faced relay attacks, where adversaries employ man-in-the-middle techniques to extend the effective communication distance between a legitimate card or and the , enabling unauthorized remote transactions. These attacks exploit the short-range nature of NFC protocols by relaying signals through intermediate devices, potentially allowing fraudsters to initiate payments from afar without the cardholder's physical presence. To counter this, distance-bounding protocols have been proposed in for potential integration into EMV specifications, which measure the round-trip time of challenge-response messages to verify proximity and reject relayed signals exceeding predefined thresholds. A 2025 systemization of knowledge on EMV systems highlights ongoing vulnerabilities, such as the transmission of untokenized Track 1/2 data (including primary account numbers and expiry dates), enabling attacks using commercial NFC readers. Tokenization in mobile EMV implementations, while designed to replace sensitive primary account numbers with secure tokens, can still expose risks if untokenized data is transmitted in , allowing on PAN and expiry dates via NFC readers. Key countermeasures include mandating online PIN verification for high-value contactless transactions to prevent unauthorized approvals, implementing across the payment chain to protect data in transit, and requiring regular updates to EMV contactless kernels to patch emerging vulnerabilities. These measures collectively strengthen EMV's resilience against evolving threats in mobile and remote environments.

Global Implementation

Regional Adoption Patterns

Europe led the global adoption of EMV technology, driven by a mandate for Chip and PIN implementation across the (SEPA), achieving nearly 100% card and terminal compliance by 2011. The initiated its nationwide rollout between 2003 and 2005, becoming one of the first markets to fully transition to chip-based payments, which significantly reduced counterfeit fraud. In , completed its EMV migration ahead of many peers, reaching full adoption of chip-enabled cards and terminals by , with over 90% of ATMs also compliant by that time. The followed with a slower pace but accelerated after the 2015 liability shift, which transferred fraud responsibility to non-compliant merchants and issuers; as of 2025, approximately 68% of payment cards in circulation were EMV-enabled, contributing to an 87% decline in counterfeit since the shift. The region saw varied but robust EMV uptake, with emerging as an by completing its nationwide migration to chip cards in 2005, the first in the area, resulting in an 85% reduction in card fraud from 2003 levels. enforced a mandate in 2014, leading to widespread compliance and high integration with contactless features, where contactless transactions now account for a significant portion of payments. Latin America experienced later but determined adoption, with achieving full EMV migration for contact cards by 2015, followed by reaching 100% compliance by the same year, though broader regional rollout continued into the early . In the and , implementation has been more heterogeneous, with the attaining high EMV adoption through coordinated industry efforts, while has initiated efforts to transition fleet and retail payments to chip technology. As of Q4 2024, global EMV chip card deployment reached 71.98% of issued cards, with 96.20% of card-present transactions processed via EMV methods; regional variations persist, with and parts of nearing full compliance.

White Label EMV Cards

White label EMV cards are EMV-compliant payment cards that enable private issuers, domestic networks, or closed-loop systems to brand and issue customized cards without direct reliance on major international schemes such as Visa or Mastercard. These cards utilize standardized EMV kernels, including PURE, recognized as the world's first white-label EMV kernel, to support tailored implementations for specific ecosystems like transit or private label programs. White label EMV cards, including those using the PURE kernel, undergo rigorous testing and certification processes to ensure compliance and security. These include EMVCo's Level 1 testing, which evaluates hardware and basic functionality, and Level 2 testing, which assesses application-level compliance with EMV specifications. Additionally, the PURE certification scheme provides assessment and certification services based on PURE specifications, including a dedicated test plan that enables fast certification for kernel products. Tools such as EMV Personalization Validation Test Tools support validation for PURE white label cards prior to formal certification. Furthermore, PURE's certification scheme extends to POS terminals and other components, including testing for contactless kernels in EMV-compliant payment POS terminals, ensuring comprehensive ecosystem compliance. The White Label Alliance develops EMV-compliant standards that facilitate these implementations, promoting interoperability and security for non-traditional issuers in domestic and private label contexts. White label EMV cards contribute to global adoption by allowing localized and customized deployments that align with regional needs, particularly in transit and closed-loop environments. For instance, transit operators can issue branded EMV cards, such as those powered by White Label Alliance technology for contactless access control, enhancing customer experience in public transport systems across various regions. In Europe, they support domestic payment networks, while in North America, examples include private branded EMV prepaid cards for urban transit like New York City's OMNY system.

Integration with [Contactless payments](/page/Contactless payments) and Mobile Payments

EMV [contactless payments](/page/Contactless payments) enable secure, tap-to-pay transactions using (NFC) technology, where cards or devices are held near a terminal without physical insertion. This functionality is built on the EMV Contactless Chip specifications, which ensure compatibility with existing payment infrastructure while maintaining chip-based security features like dynamic data authentication. Major payment networks have branded implementations: Mastercard's PayPass and Visa's payWave, both adhering to EMV standards for . By 2025, [contactless payments](/page/Contactless payments) adoption has reached over 90% in many global markets, such as 97% in , reflecting widespread terminal support for these EMV-compliant transactions. In mobile payments, EMV integrates with digital wallets through Host Card Emulation (HCE), a software-based approach that allows smartphones to emulate [contactless payments](/page/Contactless payments) cards without relying solely on hardware secure elements. On Android, HCE enables apps to handle NFC interactions directly, processing EMV kernels for transaction authorization. iOS introduced HCE support in version 17.4 and later, permitting developers to implement [contactless payments](/page/Contactless payments) within apps using EMV-compliant protocols. Leading mobile wallets like Apple Pay and Google Pay leverage these EMV kernels to execute secure tap transactions, combining device-bound keys with network authentication for fraud prevention. Apple Pay primarily uses a dedicated secure element for credential storage, while Google Pay employs HCE for broader flexibility across devices. EMV tokenization enhances mobile payment security by replacing sensitive primary account numbers (PANs) with unique, device-specific tokens provisioned via the EMV Payment Tokenisation Specification. Token service providers (TSPs) issue these tokens through a standardized framework, enabling secure provisioning to NFC-enabled devices or wallets while restricting token usage to authorized domains. This process supports seamless integration in [contactless payments](/page/Contactless payments) scenarios, as tokens are validated during EMV kernel processing without exposing the underlying card details. The specification outlines roles for issuers, networks, and TSPs to ensure tokens are cryptographically bound and revocable, bolstering protection against interception in mobile environments. Despite these advancements, EMV mobile implementations face challenges, including trade-offs between secure elements (hardware-based isolation for credentials) and HCE (software emulation reliant on device OS and cloud verification). Secure elements offer tamper-resistant storage but limit flexibility due to carrier or manufacturer control, whereas HCE enables easier provisioning yet increases vulnerability to or network dependencies. Battery life concerns arise in HCE scenarios, as frequent NFC polling and cryptographic operations can accelerate drain compared to passive secure element modes. In 2024, EMVCo addressed range-related issues for wearables and Tap-to-Mobile devices by introducing a reduced range approval process, defining compliance levels with minimized read distances to improve and power on resource-constrained hardware. This initiative supports broader adoption of EMV in wearables by optimizing NFC interactions for shorter, more secure taps.

Standards and Documents

Core EMV Books and Levels

The EMV specifications are organized into a series of foundational "books" that outline the technical requirements for integrated circuit card (ICC) payment systems, ensuring interoperability and security across global payment infrastructures. These books form the core of the EMV standard, with Book 1 addressing application-independent aspects of the interface between the ICC and the terminal. It defines the general requirements for data elements, commands, and responses exchanged during transactions, independent of specific payment applications, to facilitate consistent communication protocols. Book 2 focuses on security and , specifying the cryptographic mechanisms used to cards and protect transaction data. It details offline and online data methods, such as static and dynamic data , along with , distribution, and management procedures to prevent and ensure . Book 3 covers the application specification, with a particular emphasis on personal identification number (PIN) handling as part of cardholder verification methods (CVMs). It outlines the functional requirements for application selection, , and verification processes, including how the terminal and card negotiate and perform PIN-based to confirm the cardholder's identity. Book 4 specifies the requirements for interfaces between the cardholder, attendant, and acquirer in payment systems, including cardholder verification (such as PIN entry and signature capture), attendant interactions, and acquirer scripting for post-issuance updates. Note that contactless payments are addressed in supplemental EMV Contactless Specifications, including Books A (Application), B (Entry Point), E (Security and Key Management), and C-series kernels. The C-series kernels are specific to certain payment brands, such as C-2 for , C-3 for Visa, C-4 for , C-5 for JCB J/Speedy, C-6 for Diners Club/Discover D-PAS, C-7 for China UnionPay QuickPass, and C-8 as a unified kernel supporting multiple schemes, including major international payment schemes such as Mastercard, Visa, American Express, Discover, JCB, and UnionPay, and designed to be royalty-free for local schemes as well, as defined in the EMV Contactless Specifications. These kernels specify the scheme-specific processes for contactless transactions, including card application selection, data authentication (using methods from Book E), and transaction authorization, with each kernel tailored to its payment scheme's requirements. The C-8 kernel unifies support for multiple schemes using advanced cryptography like ECDH for key agreement and is designed for broader adoption including local schemes without royalties. These contactless specifications have their own versioning separate from the core books; for example, Book B (Entry Point Specification) is at version 2.11 (published April 2024), Book E (Security and Key Management) at version 1.1 (published April 2025), and the C-8 kernel at version 1.1 (published April 2025). For the latest versions, refer to the EMVCo specifications page. EMV certification operates through a hierarchical structure of three levels to validate compliance with these specifications. These levels apply to acceptance devices (such as payment terminals), chip cards, and mobile payment form factors, with distinctions between contact and contactless interfaces where applicable. For acceptance devices, Level 1 certification tests interface compliance, focusing on the physical, electrical, and requirements to ensure they meet hardware standards. For contact interfaces, this includes compliance with and EMV Book 1 for application-independent aspects. For contactless interfaces, it tests compliance with EMV Contactless Specifications, including physical and electrical requirements specific to contactless communication and standards like [ISO/IEC 14443](/page/ISO/IEC 14443). Level 2 certification evaluates protocol testing, verifying that the software kernel correctly handles command-response sequences, authentication, and transaction flows. For contact implementations, this covers EMV Books 1, 2, 3, and 4. For contactless implementations, it verifies contactless kernels implementing the EMV Contactless Specifications, including Books A, B, E, and C-series kernels; for the C-8 kernel, this verifies compliance for all supported schemes. Level 3 certification assesses application-level integration, confirming that the full payment solution, including host systems, processes EMV transactions end-to-end without errors or vulnerabilities in accordance with the overall EMV specifications. EMVCo manages the EMV Level 3 (L3) Testing Framework and the qualification process for related L3 test tools, which validates the integration of an EMV acceptance device with its acceptance infrastructure and standardizes L3 test tools using machine-readable formats. Payment schemes may impose additional scheme-specific requirements, such as Visa's Message-Level Validation (MLV), a script-based field-level validation against Visa specifications that serves as a prerequisite for beginning EMV Level 3 certification, and attended host testing for certain implementations like contactless transit terminals, illustrating how schemes extend EMVCo's framework with further validation processes. For chip cards, Level 1 certification similarly focuses on hardware and interface compliance. Contact chip cards are tested against and EMV Book 1 requirements for physical, electrical, and transport layers. Contactless chip cards undergo Level 1 testing for compliance with EMV Contactless Specifications and [ISO/IEC 14443](/page/ISO/IEC 14443). Level 2 certification verifies the card's software kernel implementation, ensuring correct handling of EMV Books 1-4 for contact or contactless specifications (Books A, B, E, C-series) for contactless, including scheme-specific compliance for kernels like C-8. Level 3 testing for chip cards evaluates end-to-end application integration within the card's ecosystem, ensuring seamless transaction processing without vulnerabilities. For mobile payment form factors, which often emulate EMV chip cards via host card emulation (HCE) or secure elements, certification follows a similar structure with an emphasis on contactless capabilities. Level 1 testing covers physical and electrical compliance, primarily for contactless interfaces under [ISO/IEC 14443](/page/ISO/IEC 14443) and EMV Contactless Specifications, though some mobile solutions may include contact testing if applicable. Level 2 certification assesses the mobile kernel's protocol implementation, verifying compliance with EMV Contactless Specifications, including Books A, B, E, and C-series kernels for supported payment schemes. Level 3 certification ensures application-level integration with the mobile device's host systems and payment infrastructure, validating secure end-to-end EMV transaction flows. The baseline version for the core Books 1, 2, 3, and 4 is EMV 4.4, released in October 2022, which serves as a foundational reference with subsequent errata bulletins addressing clarifications and minor corrections. Kernel validation during certification relies on card data (ICD) files, which provide vectors and scenarios derived from the specifications to simulate real-world interactions and verify accuracy. Public access to the EMV specifications, including the core books up to version 4.4, is available through the EMVCo website, where registered users can download documents for purposes; however, certain proprietary elements, such as detailed scripts or member-specific extensions, remain confidential to EMVCo associates.

Recent Updates and Future Directions

In 2024, EMVCo published the Secure Remote Commerce (SRC) specifications for public access on May 8, establishing a standardized framework for secure payments that simplifies checkouts across devices and merchants. Later that year, on , EMVCo introduced the Reduced Range Level 1 Type Approval Process, defining compliance levels for acceptance on consumer devices such as smartphones, enabling enhanced Tap to Mobile experiences with optimized reading ranges for better usability in everyday scenarios. Additionally, on October 16, EMVCo launched the testing process for the EMV Contactless Kernel Specification, providing detailed guidance on certification requirements to ensure and in contactless payment kernels. Moving into 2025, EMVCo issued Directive and Specification Bulletin (DSB) No. 315 on EMV TEST PCD-2, a new standard for testing proximity coupling devices used in contactless EMV systems, with the public comment period scheduled to conclude on November 30 to refine tools for more accurate validation of payment terminals. Looking ahead, EMVCo is actively monitoring advancements in quantum-resistant cryptography through collaboration with NIST, with plans to assess and potentially integrate these into future EMV specifications to mitigate long-term threats from quantum computing, which are not anticipated to impact current infrastructure until at least 2040. The organization also envisions expanded application of SRC technology to Internet of Things (IoT) payment scenarios, such as seamless integration for electric vehicle charging stations, as demonstrated in ongoing pilots that leverage SRC for secure, automated transactions without physical cards. These directions build on core EMV books by evolving specifications to address emerging digital ecosystems while maintaining backward compatibility.

References

Add your contribution
Related Hubs
User Avatar
No comments yet.