Visa Rejected the Dispute, Can the Credit Union do the Same?

Question:

Hi Heather,
Our credit union has a question about a Visa Dispute we filed for a member. Some background:

  • The member is disputing several transactions made through Cash App going all the way back to at least December, most of them in the member’s name.
  • The member claims to not have noticed the transactions leaving her account, but she regularly logs into her online banking account and some of the Cash App withdrawals were quite large, so I’m not sure how she missed them!
  • The credit union filed 90 days’ worth transactions via our card processor with Visa (the limit). However, the dispute was declined due to a Visa ruling code 10.4.
  • Our card processor is stating that because there are prior undisputed transactions with the subject merchant, Visa is rejecting all disputes against the merchant.
  • In their response, our card processor also added an attachment that shows the account ID for the transactions matches the phone number we have on file for our member.

 

We are wondering, if, based off the information we received, we can put liability back on the member or if this is something the CU still has to take a loss for. We don’t believe our member has been unaware these transactions were happening.

 

Answer: 

Well, that’s a great question. I have some good news and some bad news.

Bad news first:

  • What Visa will or will not do has no bearing on the responsibility of the card issuer under Reg E.
  • Reg E has very broad consumer protections for card holders. Issuers will almost always end up holding the bag for unauthorized transactions.
  • In the case of unauthorized transactions, the credit union can’t get off the hook simply because previous transactions to the same merchant were authorized – it’s completely possible some transactions were authorized and some were not, especially with a P2P payment app like Cash App.
  • The credit union also can’t get off the hook because the phone number associated with the transactions is your member’s phone number. It doesn’t prove anything except the transactions originated from her phone.
  • The credit union must have more proof the member authorized the subject transactions before it can deny a dispute. For example, It’s totally possible a friend or family member has been sneaking your member’s phone to make transactions without her permission. Visa might not be on the hook for those unauthorized transactions, but the credit union is.

 

Now the good news:

  • The transactions started in December! You can stop the bleeding, and no matter what, the credit union will not be on the hook for all of the transactions.
  • The member had a duty to review her statements and promptly report unauthorized transactions. She will be responsible for any transactions that occurred more than 60 days after the first unauthorized transactions appeared on her statement.
  • Since the problematic transactions started in December 2023, those transactions would have appeared on the statement mailed to your member on or around January 1. Let’s say you guys mailed the December statement on January 2. Your member would have until March 2 to report the unauthorized transactions to the credit union. Since she didn’t, all transactions that occurred after March 2, are 100% on her. The transactions that occurred on March 2 and prior, the credit union will have to eat.

 

What to do now:

  • If you think your member is lying to you or you don’t want to be on the hook again for her poor Cash App/mobile phone security, the credit union can always close down the debit card that was linked to the member’ Cash App and not re-issue. Or close down ACH ability on her checking or share account. Or close down any transfers to Cash App and any other P2P payment providers (if you can)
  • I assume we are talking about a debit card, checking, or share account that was hooked up to Cash App.  If that isn’t the case, let me know. My answer of what you can do to prevent future issues will be different if a credit card was used.