EMV chip technology shifted counterfeit fraud liability. The party with weaker security pays for fraud. If your terminal doesn't support chip and a chip card is used fraudulently, you're liable.
Understanding liability shift helps you make informed decisions about terminal upgrades and transaction handling.
How Liability Shift Works
The Basic Rule
Liability falls on the party with less secure technology.
| Merchant Has | Card Has | Liability |
|---|
| Chip terminal | Chip | Issuer |
| Chip terminal | No chip (mag-stripe) | Issuer |
| No chip terminal | Chip | Merchant |
| No chip terminal | No chip | Issuer |
Pre-EMV (Before October 2015)
Before liability shift:
- Issuer liable for most card-present fraud
- Merchant could swipe any card
- Counterfeit cards worked at any terminal
Post-EMV (After October 2015)
After liability shift:
- If merchant could have used chip but didn't → merchant liable
- If issuer could have issued chip but didn't → issuer liable
- Counterfeit chip cards much harder to create
What "Chip Terminal" Really Means
Having a terminal with a chip slot isn't enough. To get liability shift:
Requirements
| Requirement | Why It Matters |
|---|
| EMV-capable terminal | Hardware must support chip |
| EMV enabled | Chip must be activated, not disabled |
| EMV certification | Terminal must be certified by networks |
| Chip used on transaction | Must actually dip/tap, not swipe |
Common Mistakes
| Mistake | Result |
|---|
| Chip terminal but EMV not enabled | No liability shift |
| Customer swipes chip card | No liability shift |
| Fallback to swipe after chip error | Partial protection (varies) |
| Keyed entry | No liability shift |
Transaction Types and Liability
- Card inserted into chip slot
- Most secure for card-present
- Full liability shift to issuer for counterfeit
- Card or device tapped on terminal
- Uses EMV technology
- Liability shift applies
- Includes Apple Pay, Google Pay (tokenized)
Swipe (Mag-Stripe)
- Magnetic stripe read
- No liability shift if chip card
- Acceptable for non-chip cards
- Falling back to swipe loses protection
Keyed (Manual Entry)
- Numbers typed manually
- No chip or swipe
- Never gets liability shift
- Highest risk transaction type
Fallback Transactions
When chip fails and you fall back to swipe:
What Causes Fallback
| Cause | Frequency |
|---|
| Dirty/damaged chip | Common |
| Terminal chip reader issue | Common |
| Card chip malfunction | Occasional |
| Fraud attempt (manipulated card) | Rare |
Fallback Liability Rules
| Scenario | Liability |
|---|
| First fallback | Often protected (varies by network) |
| Repeated fallback same card | Loses protection |
| Fallback after chip read failed | Some protection |
| Fallback without attempting chip | No protection |
Fallback Best Practices
- Always attempt chip first
- Re-insert chip if first attempt fails
- Clean chip reader regularly
- Request different card if repeated failure
- Document fallback reasons
Reason Codes for Liability Shift Disputes
Visa
| Code | Name | When Used |
|---|
| 10.5 | Visa Fraud Monitoring Program | High fraud merchant |
Note: Visa consolidated fraud codes. EMV liability disputes filed under fraud category with specific data elements indicating liability shift claim.
Mastercard
| Code | Name | When Used |
|---|
| 4870 | Chip Liability Shift - Counterfeit | Chip card used at non-chip terminal |
| 4871 | Chip Liability Shift - Lost/Stolen | Chip card lost/stolen, used at non-chip terminal |
Amex
| Code | Name | When Used |
|---|
| F30 | EMV Counterfeit | Counterfeit chip card |
| F31 | EMV Lost/Stolen/NRI | Lost, stolen, or never received |
Discover
| Code | Name | When Used |
|---|
| UA05 | Fraud - Chip Card | EMV counterfeit |
| UA06 | Fraud - Chip Card Lost/Stolen | EMV lost/stolen |
Fighting EMV Liability Chargebacks
When You Can Win
| Scenario | Defense |
|---|
| Chip was actually used | Provide chip transaction receipt showing EMV data |
| Terminal is certified | Provide EMV certification documentation |
| Card wasn't chip-enabled | BIN data showing non-chip card |
| Technical malfunction documented | Terminal logs showing forced fallback |
When You'll Likely Lose
| Scenario | Why |
|---|
| Swiped a chip card | Didn't use available technology |
| Keyed a transaction | No verification at all |
| EMV not enabled | Configuration issue = your fault |
| Repeated fallback | Pattern suggests avoidance |
Evidence to Collect
| Evidence | Purpose |
|---|
| Transaction receipt | Shows entry method (chip/swipe/keyed) |
| Terminal certification docs | Proves EMV capability |
| Terminal batch report | Shows transaction details |
| Chip data (ARQC/TC) | Cryptographic proof of chip use |
Mobile Wallets (Apple Pay, Google Pay)
| Factor | Liability Implication |
|---|
| Tokenized | Token represents card, not actual number |
| Device authentication | Biometric or PIN on device |
| Liability | Generally shifts to issuer |
Mobile wallet transactions typically provide strong liability protection because:
- Token is device-bound
- Requires device authentication
- Transaction includes device data
| Factor | Liability Implication |
|---|
| EMV contactless | Uses chip technology wirelessly |
| Liability shift | Yes, same as chip dip |
| Fraud rate | Generally low |
Special Cases
Card-Present but Keyed
Sometimes you have the card but can't dip/swipe:
- Damaged chip and mag-stripe
- Reader malfunction
- Phone order with card in hand
Liability: Still yours. Network rules don't care why you keyed.
Best practice: If chip and swipe both fail, request different payment method or decline transaction.
Hotel and Rental Pre-Authorization
| Scenario | Liability |
|---|
| Initial auth (check-in) | Chip used = protected |
| Incremental auth | May not require card-present |
| Final capture | Based on original auth |
Hotels and rentals have special rules allowing delayed/incremental charges. Liability depends on original authorization method.
Recurring Transactions
| Scenario | Liability |
|---|
| Initial chip transaction | Protected |
| Subsequent recurring | MIT (merchant-initiated) rules apply |
| Stored credential | Based on original capture method |
Recurring billing after initial chip transaction generally maintains protection, but rules are complex. Check with your processor.
Terminal Compliance
EMV Certification Process
| Step | Description |
|---|
| 1. Hardware | Terminal must support EMV |
| 2. Software | EMV application loaded |
| 3. L2 certification | Network-specific testing |
| 4. L3 certification | Processor/acquirer testing |
| 5. Deployment | Activated in production |
Maintaining Compliance
| Action | Frequency |
|---|
| Firmware updates | As released |
| Certification renewals | Per network requirements |
| Security patches | Immediately |
| Reader cleaning | Weekly minimum |
Terminal Inspection Checklist
Regional and Network Variations
Visa
- Liability shift effective October 2015 (US)
- Gas stations extended to October 2020
- Specific rules for quick service restaurants
Mastercard
- Similar timeline to Visa
- Specific rules for certain MCCs
- Standin processing rules
American Express
- Liability shift effective October 2015
- SafeKey (3DS) for CNP liability
- Different rules for OptBlue merchants
Discover
- ProtectBuy for authentication
- Similar chip liability rules
- Smaller issuer base
Future: Tap-to-Phone
Emerging technology allows phones to act as terminals:
| Factor | Status |
|---|
| Technology | Phone accepts contactless payments |
| Certification | Network programs exist (Visa Tap to Phone, etc.) |
| Liability shift | Generally applies |
| Security | Software-based security model |
Watch this space for evolving rules.
Scale Callout
| Volume | Focus |
|---|
| Under $50k/mo CP | Ensure terminals are EMV-enabled. Don't overthink. |
| $50k-$250k/mo CP | Monitor fallback rates. Clean readers regularly. |
| $250k-$1M/mo CP | Track liability shift chargebacks. Investigate patterns. |
| Over $1M/mo CP | Dedicated terminal management. Regular certification audits. |
Where This Breaks
-
Assuming chip = protected. Terminal must be certified AND EMV enabled AND chip actually used. Check all boxes.
-
Ignoring fallback rates. High fallback rates signal terminal issues—and potential liability gaps. Monitor and fix.
-
Keyed transactions for "convenience." Every keyed transaction is liability exposure. Minimize ruthlessly.
Related Pages