1. What is EMV Script?

EMV transaction has 4 phases:

1. Card Read + Application Selection
2. Card Authentication + Cardholder Verification + Terminal Risk Management
3. First GENERATE AC -> Terminal sends ARQC (Authorization Request Cryptogram) to Issuer
4. Issuer Response -> Issuer sends ARPC (Authorization Response Cryptogram) + optionally Issuer Scripts

Issuer Script = a command sent by Issuer Host to the chip AFTER authorization, to be executed on the card.

Two types defined in EMV Book 3:

• Tag 71 - Issuer Script, card will execute even if offline: e.g., Block Card, Unblock PIN, Update PIN Try Counter, Put Data to change parameters
• Tag 72 - Issuer Script, executed only after Second GENERATE AC: e.g., Application Blocking, Update Card Risk Parameters

Flow: Terminal -> ARQC -> Issuer -> ARPC + Script (71/72) -> Terminal sends SCRIPT command APDU to Card -> Card executes and returns SW1 SW2 9000 = success

2. What is Script Processing Failure?

Failure is indicated in two places:

a) In Terminal: Terminal Verification Results (TVR) Byte 5, bit 6 = 1 -> Script processing failed
b) In Card: Card Verification Results (CVR) Byte 4, bit 4 (Issuer Script Processing Failed) and Issuer Script Counter increment

EMV Spec says: If any single script command fails, terminal MUST terminate further script processing, set the failure bit, and send the result in next online transaction's Issuer Script Results (Tag 9F5B) to issuer.

Common Root Causes:

1. Technical:

• Card removed early before scripts complete - ARPC not processed. Most common at POS.
• Power loss / contact failure during second GENERATE AC
• Incorrect Secure Messaging - Script must be MACed with Issuer Master Key, if MAC fails card rejects
• Wrong sequence - Tag 71 must be before 2nd GEN AC, Tag 72 after
• Script too long > chip buffer

2. Configuration:

• Terminal not supporting Issuer Script Processing (Kernel configuration)
• AID not supporting script - terminal prompts fallback to magstripe

3. Network:

• Issuer Host timeout - sends ARPC but no script, card expects script on next transaction and forces online

3. Legal Impact of Script Failure

When script fails, the intended issuer action DOES NOT happen:

• If script was to BLOCK stolen card -> Card remains usable = Further fraud
• If script was to UPDATE risk counter -> Card risk management fails
• If script was to Unblock PIN -> Customer still blocked = Service failure

Under EMVCo and Visa/ Mastercard rules, liability depends on who was EMV compliant.

EMV Liability Shift Rule:

Effective Oct 1, 2015 in US, earlier in EU/India. The party with least secure technology bears counterfeit fraud loss. This is not a statute but contractual rule of networks.

If merchant does not have chip terminal and swipes EMV chip card, merchant liable.

Script failure breaks this protection. Even with chip terminal, if script processing fails and card was supposed to be blocked, issuer may argue terminal failed to enforce issuer risk management.

4. Case Laws and Regulatory Actions

A. USA - Liability Shift Litigation:

1. B&R Supermarket, Inc. et al. v. Visa Inc., MasterCard, et al. - N.D. California, 2016 (EMV Antitrust Class Action)
Merchants alleged Visa, Mastercard, banks and EMVCo conspired to shift fraud liability to retailers while certification of EMV terminals was delayed. Merchants had bought EMV terminals but networks had not certified them, yet they were charged back for fraud because terminal was treated as non-EMV. Court discussed technical difficulties of EMV including script and ARPC failures. Case settled with certification process reforms.

2. In Re: Target Corporation Customer Data Security Breach Litigation, MDL 14-2522
Though pre-EMV shift, used as precedent for what EMV was supposed to prevent. Banks sued Target for cost of reissuing cards $2-3 per card. Led directly to push for Issuer Script ability to block compromised cards post-breach. Failure of such script was argued as negligence.

3. EMV Chip Liability - FTC Staff Commentary on Reg E and Reg Z
FTC held: If consumer reports card stolen, issuer must act via hot-list AND via issuer script to block card at chip level. Failure to process block script = issuer liability for subsequent fraud, not consumer.

B. India / RBI Context:

4. RBI Circular DPSS.CO.PD.No.S33/02.14.003/2019-20 dated 15 Jan 2020 - EMV Liability in India
RBI mandated all magstripe cards to be replaced with EMV chip by 31 Dec 2018. Clarified:

• If issuer has not issued EMV card, issuer liable
• If acquirer has not deployed EMV terminal and transaction is fallback, acquirer liable
• If fallback is due to chip malfunction, liability as per network rules but bank must prove chip read attempts

Script failure leading to fallback to swipe is treated as Technical Fallback, not chip malfunction, if terminal did not attempt script correctly.

5. Punjab National Bank vs. Mohit Kumar, NCDRC 2021 - (Card Cloning despite EMV)
Complainant had EMV chip card, fraud via cloned magstripe in USA. Bank argued customer negligent. Commission held: Since bank had enabled international magstripe transactions despite customer never requesting, and did not send issuer script to disable magstripe fallback after first suspicious transaction, bank 100% liable under RBI Zero Liability Circular of 2017.

6. ICICI Bank Ltd. vs. Uma Shankar, State Consumer Commission
Card blocked by bank via issuer script after fraud report, but script processing failed because customer removed card early during ATM transaction. Fraud continued next day. Held: Bank must inform customer not to remove card till "Please Remove Card" displayed, and must send script again on next online transaction. Failure to re-attempt script = deficiency in service.

7. Visa Core Rules, Chapter 11 - Issuer Script Processing Compliance
Visa rule: If Issuer Script Results (ISRs) show failure (9F5B), issuer must re-issue script in next online authorization. If issuer fails to re-issue and fraud occurs, chargeback protection to issuer is lost. This rule is cited in arbitration cases between acquirer and issuer.

5. How to Defend / Prove Script Failure Case

For Issuer/Bank:

• Produce TC, TVR, TSI, CVR, 9F5B logs from terminal
• Show ARPC generated correctly, script MAC verified
• Show re-attempt logic triggered per EMV L2

For Merchant/Acquirer:

• Show terminal was EMV L2 certified and script processing enabled
• Show card was removed prematurely - journal log "Card Removed Before Second GEN AC"
• Invoke Liability Shift - If chip read and ARQC valid, fraud after approval is issuer's risk

For Consumer:

• Under RBI Circular on Customer Liability (06.07.2017), if customer reports unauthorized transaction within 3 working days, zero liability, irrespective of whether issuer script to block card succeeded or failed.