EMV chip and ARQC: how a chip card proves it is genuine

EMV is the global standard for chip cards, named after Europay, Mastercard and Visa, and it is the reason a chip card is far harder to copy than a magnetic stripe card. The chip is a small computer that holds secret keys and can perform cryptographic calculations, and every time the card is used it generates a unique cryptogram that proves the card is genuine and that the transaction details have not been altered. The most important cryptogram is the ARQC, the Authorisation Request Cryptogram, which is generated by the chip and sent to the issuer for verification. If the ARQC is correct, the issuer knows the card is genuine; if it is wrong, the card is a copy. Why EMV exists is that magnetic stripe cards are trivially easy to copy: the stripe holds static data that can be read, copied to a blank card, and used to make fraudulent purchases. This is called skimming, and it cost the card industry billions of dollars a year. The chip solves the problem by never revealing its secret key and by generating a different cryptogram for every transaction, so a copied cryptogram is useless. The liability shift, introduced by Visa and Mastercard in 2015 in the United States and earlier elsewhere, made the party that had not adopted EMV liable for counterfeit fraud, which drove global adoption. EMVCo, the body that owns the standard, publishes the specifications and certifies the chips and terminals. The parties are the cardholder, the merchant, the terminal, the acquirer, the card scheme, and the issuer. The chip holds the card data, the issuer keys, and the application that generates the cryptogram. The terminal reads the chip, sends the transaction details to it, and receives the ARQC. The acquirer forwards the authorisation request, including the ARQC and the EMV data in ISO 8583 field 55, to the scheme, which routes it to the issuer. The issuer verifies the ARQC using its copy of the card keys, and if it matches, the card is genuine. The issuer then makes its authorisation decision based on the account balance, the fraud score, and the transaction details. In practice the ARQC generation works like this. The terminal sends the transaction amount, currency, date, terminal country, and a random unpredictable number to the chip. The chip combines these with its transaction counter, which increments on every transaction, and encrypts the result with the card unique derived key, producing the ARQC. The chip also produces the application transaction counter and the issuer application data, which are sent with the ARQC. The issuer decrypts the ARQC using its master key and the card number, recomputes the expected value, and compares it. If they match, the card is genuine and the transaction details are unaltered. If the transaction counter is lower than the last one the issuer saw, the card may have been cloned, and the issuer declines. A worked example shows the numbers. A customer buys groceries for GBP 45.20 at a supermarket in London. The terminal sends the amount 4520, the currency code 826 for sterling, the date, and an unpredictable number 8F3A21C4 to the chip. The chip transaction counter is 1,247. The chip generates an ARQC of, for example, 9C4E2A71B8D305F6, and the terminal sends the authorisation request with ISO 8583 field 55 containing the ARQC, the counter and the issuer application data. The issuer verifies the ARQC, checks the account balance, and returns an approval with response code 00 and an authorisation code. The whole process takes under two seconds, and the cryptogram is never reused. What happens when the ARQC fails is a decline, and the reason matters. If the ARQC is wrong because the card is a copy, the issuer returns response code 05, do not honour, and the terminal declines the transaction. If the transaction counter is out of sequence, the issuer may decline and ask the cardholder to contact the bank, because the card may have been cloned. If the chip cannot be read, the terminal falls back to the magnetic stripe, but the liability for any fraud then sits with the party that allowed the fallback, and many issuers decline fallback transactions above a low value. The operations team must monitor the fallback rate, because a sudden rise means terminals are failing or fraudsters are forcing fallback. The operational and accounting implications are that the issuer must manage its keys securely, the acquirer must ensure its terminals support EMV and send field 55 correctly, and the scheme must certify both. On the ledger, an EMV authorisation creates a hold on the cardholder account for the transaction amount, exactly as a magnetic stripe authorisation does, but the fraud loss rate is far lower. The finance team must track the counterfeit fraud rate separately for chip and stripe transactions, because the liability shift means the party that has not adopted EMV pays for the fraud, and that cost must be allocated correctly. For a business analyst, EMV is a certification and data subject. When you specify a terminal or an issuer host, you must list the EMV kernel version, the field 55 data elements, the ARQC verification procedure, the fallback rules, and the liability shift consequences. You must also specify the test cases: a valid ARQC, an invalid ARQC, an out-of-sequence counter, a chip read failure, and a fallback transaction. A common gap is failing to specify what the terminal does when the chip returns an error, because the terminal behaviour in that case determines who bears the fraud loss. Takeaway: the chip does not store a secret that can be copied, it proves itself fresh on every transaction, and that is why counterfeit fraud collapsed where EMV was adopted. Further reading: the EMVCo EMV specifications for the chip and the ARQC; the Visa Core Rules for authorisation; the Mastercard rules for EMV processing. Last reviewed 7 November 2026. A terminal that falls back to the magnetic stripe gives away that proof, which is why fallback is limited and monitored.