Skip to main content

Visa 11.1 - Card Recovery Bulletin

TL;DR
  • You processed a card that was on the Card Recovery Bulletin, the hot card list. Liability moved to you
  • Mostly card-present. Your terminal should have returned "pick up card" (04, 07, 41 or 43) and you should have declined
  • Dispute window is 120 days from the transaction date
  • Representment options are thin. You need proof the card wasn't listed when you ran it
  • Prevention is a terminal that checks the CRB and staff who don't override a decline

Transaction processed on a card that was on the Card Recovery Bulletin (CRB), also known as the "hot card list."

Overview​

Issuers put lost, stolen and fraudulent cards on the CRB. Your terminal is supposed to check that list before it approves a card-present sale. Run the card anyway and the loss is yours, not the issuer's.

When This Code Applies​

  • The card was on the CRB when you ran it
  • Your terminal skipped the check or ignored it
  • You completed the sale even though the card was listed
  • Almost always card-present, rarely e-commerce

Conditions for Valid Dispute​

Issuer Must Verify​

  1. The card was on the CRB at sale time
  2. The cardholder says they didn't make the purchase
  3. The card was already blocked or cancelled

Transaction Requirements​

  • The sale was card-present
  • Your terminal should have returned "pick up card" or similar
  • The sale fell inside the CRB publication window

Time Frames​

ScenarioDispute Window
Standard120 days from transaction date

CRB Process​

How CRB Works​

  1. The cardholder reports the card lost, stolen or fraudulent
  2. The issuer adds it to the Card Recovery Bulletin
  3. The bulletin goes out to acquirers and terminals
  4. Your terminal should decline, and staff retain the card if it's safe

Terminal Response Codes​

CodeMeaningMerchant Action
04Pick up cardDecline, retain if safe
07Pick up card (special)Decline, retain if safe
41Lost cardDecline
43Stolen cardDecline

Representment Options​

Your options are thin. You're either proving the card wasn't listed when you ran it, or proving you got a clean approval back.

1. Card Not on CRB at Transaction Time​

Evidence required:

  • Timestamp of transaction
  • CRB publication records
  • Proof card added to CRB after transaction

2. Authorization Obtained​

Evidence required:

  • Auth approval code
  • Auth request/response logs
  • No "pick up card" response received

3. Timing Dispute​

Evidence required:

  • Transaction timestamp
  • CRB addition timestamp
  • Proof of real-time auth check

Prevention Strategies​

Terminal Configuration​

  1. Real-time auth - every sale goes online for authorization
  2. CRB checking on - never skip the hot card list
  3. Response code handling - the terminal acts on the code

Staff Training​

  1. Decline codes - your staff knows what 04, 41 and 43 mean
  2. Card retention - retain the card only when it's safe
  3. Never override - nobody pushes a CRB decline through

System Requirements​

  1. Online terminals - turn off store-and-forward and offline auth
  2. Fresh CRB data - download on schedule if you batch
  3. Response logging - store every auth response you get

Win Rate Expectations​

Defense TypeExpected Win Rate
Card added to CRB after transaction80-90%
Auth approved (no CRB match)70-85%
Card was on CRB at transactionUnder 10%

Common Mistakes​

  1. Offline processing - you can't check the CRB offline
  2. Ignoring decline codes - selling after a "pick up" response
  3. Stale CRB data - the terminal checks last week's list
  4. No auth logging - you can't prove the auth was clean
  • 11.2 - Declined Authorization
  • 11.3 - No Authorization
  • 10.1 - EMV Counterfeit

Next Steps​

Got this chargeback?

  1. Check if card was on CRB at transaction time → Very hard to defend
  2. Verify you had valid authorization → Pull auth logs
  3. If card was on CRB → Accept the chargeback (limited defense)

Prevent future 11.1 chargebacks:

  1. Process transactions online (real-time CRB check)
  2. Update terminal CRB data regularly if offline capable
  3. Never override "pick up card" decline responses
  4. Review authorization basics

See Also​

Last updated on