Skip to main content

Visa 11.1 - Card Recovery Bulletin

Last updated . Copy page as text

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

Got this code?​

Your deadline: The date on your notice wins. Visa's standard response window is 30 days, and your processor can set an earlier one.

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

Records that answer it:

  1. Proof the card wasn't on the CRB when you ran it
  2. Authorization logs showing a valid approval
  3. The terminal's response at the time: did it return "pick up card"?

If you can't support it: If the card was on the CRB, accept the chargeback. The defense is very limited.

Next: Decide whether it's worth fighting, then build the response with the Representment Workflow.

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

Which defenses hold up​

Defense TypeRelative strength
Card added to CRB after transactionStrongest
Auth approved (no CRB match)Weaker
Card was on CRB at transactionWeakest

Track your own win rate by reason code.

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

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

Next Steps​

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​

Something wrong on this page? Email matt at paymentsandrisk.com and say what needs fixing.