EMV Card Fraud: Can Your Fraud Detection System Identify Suspect Chip Card Transactions?

Track the number of invalid Authorization Request Cryptograms (ARQCs)
Why:	Just as a valid Authorization Request Cryptogram (ARQC) indicates valid data; multiple invalid ARQCs from a single EMV card likely indicate the transaction data has been altered.
Detection Strategy:	The fraud detection system should track the number of bad ARQCs that a chip card generates using a velocity limit. A fraud detection system’s velocity limit, when exceeded, triggers a specific action by the card or terminal. The fraud detection system can trigger an application block to prevent fraudulent use until the suspicious circumstances are investigated with the cardholder or merchant. (Blocking an EMV card is an alternative but, because a blocked chip card is rendered useless and cannot be reactivated, card blocking is typically reserved for lost or stolen EMV cards.)
Test Plan:	Use a scripted test tool with a soft card database that enables you to alter transaction data for a specific test chip card and generate a sufficient number of transactions to exceed the velocity limit for your fraud detection system. Test to ensure that for any subsequent transaction by that test chip card that the proper action is taken.

Track the number of fall-back transactions from the EMV card
Why:	A fall-back transaction indicates a device encountered a problem performing the desired transaction with the chip, so the device “falls back” to processing the transaction as a magnetic strip transaction. (The device still connects to the host to send the magnetic strip transaction request online.) A card that always reverts to a fall-back transaction can be an indication of damage to the chip coupled with re-writing the magnetic stripe and altering the service code.
Detection Strategy:	When the fraud detection system identifies that transactions from an EMV card at a chip-capable terminal are repeatedly being forced into fall-back magnetic strip transactions, those transactions should be flagged as fraud suspects. Issuers should track these occurrences and decline subsequent transactions from that chip card with an appropriate action code.
Test Plan:	Use a test tool to generate an excessive number of fall-back transactions for a test chip card. (There are two ways to change the service code value: generate a number of transactions with various service codes using a scripted test tool that enables automatically overriding the existing service code with any desired value at test run time, or using a soft card database that enables you to quickly make changes to the values in the EMV card record.) Test to ensure that any subsequent transaction by that test card triggers the proper action.

< Previous Page 2 of 4

1 2 3 4 Next >