In Europe, EMV is one of the more common forms of payment. There are few acquirers remaining that don't participate in full EMV. And yet the card schemes favour an outdated CVV (Card Verification Value) standard that can easily be cloned/copied.

The CVV Standard was first implemented on a magnetic stripe as an anti-fraud measure , using this method to validate a card ensured a high degree of probability it was genuinely issued. For the early 90's, this algorithm served its purpose well. Methods for reading magnetic stripe data were not readily available on the market. Today, however, anyone with a smartphone or access to eBay can purchase various devices for reading mag stripe and chip data).

CVV2 quickly became standard in the industry (early 2000), which used the same algorithm, same keys, the service code was substituted with 000 and printed on the signature strip so it was visible to the customer. This piece of data is commonly used today as a secondary authentication method available to the Point of Interaction (typically Internet, but some merchants also use this data).

CVV2 is commonly used in conjunction with Card Not Present, AVS (Address Verification Services) and where retailers may choose to support this at the Point of Interaction.

iCVV was mandated by the card schemes with the purpose of ensuring that CVV data is encoded on the Track 2 equivalent on the EMV compliant card. Which again uses the same simplistic algorithm, has a service code of 999 and the issuer may choose to use a secondary set of Card Verification Keys.

iCVV data is checked by the card schemes if your organisation has registered and exchanged Card Verification Keys with the Scheme.

In the context of a full EMV transaction, does iCVV Checking serve a useful purpose?

The reality (in my opinion) is no... Here's why...

The Card Verification Value whether it's CVV, CVV2 or iCVV is still calculated the same way it has been for more than 30 years, using three pieces of known data and a pair or cryptographic keys (Secret). These keys are typically unique at a BIN level at best!

PAN
Expiry Date
Service Code

CVV Data is static, it won't change during the lifetime of the card, and with today's available technology, it's a trivial task to read CVV data from a card. Fraudsters know it and take advantage of this fact whilst skimming cards.

When full EMV data is acquired, this must include the ARQC (Authorisation ReQuest Cryptogram). The ARQC is calculated using more data elements specific to the transaction at that point in time, and encrypted using the UDK (Unique Derived Key) that is specific to the plastic card.

i.e. The keys used are unique to the card and generated at the time of personalisation, therefore the data is unique per transaction.

The ARQC is also 8 bytes of data. And therefore offers significantly higher security than a static three-digit number.

Why do card schemes still insist on validating the iCVV data on Full EMV transactions? (A three digit static number, as opposed to a Dynamic 8 Byte Value)

They do validate both during the transaction flow (if you subscribe to their On-Behalf-Key-Management services).

I believe this needs challenging at the industry level. Why rely and mandate an out-dated security algorithm that has no real relevance or obvious benefit in the EMV transaction world?

Changes to security practices move at a snail's pace in the payments industry, and as we look to other forms of secure payment, NFC, Apple Pay, MCX, Samsung Pay, then maybe even the ARQC will fall from grace.....

Make your thoughts known through our LinkedIn group