A debit card arrived at my house yesterday. It wanted me to activate it and link a bank account.
I didn’t order it. I don’t have a Cash App account.
The envelope had my name on it and my real home address, which raised the obvious question: where did they get that, and is somebody in the process of stealing my identity?
I work in fraud prevention, so my first instinct was to check whether this matched a known scam pattern. It resembled one from 2020. My second instinct was one most people don’t have — I went and looked at our own data.
What I found there
Over the last 90 days, bad actors ran 2.3 million searches across 158,509 compromised consumer mailboxes, hunting specifically for mail from Cash App and Square. One sender address alone — noreply@messaging.squareup.com — was searched for in 97,532 of them.
Not one of those actors cracked a password on Cash App or Square to do it.
That is the part worth sitting with. The attack isn’t happening at the login. It is happening inside the inbox, after the fact — and the messages they search for hardest are the ones a platform sends when something changes. Among the most-read is the notification that a new email address has just been linked to an account.
Which means the first evidence that something has gone wrong usually arrives in a person’s mailbox, not in a monitoring system. A human notices before a system does. Whether that ever becomes intelligence depends entirely on what happens when they pick up the phone and call you.
So I was already on guard. Then I called support.
The call
The chat option came first. It offered me a QR code and asked me to download the Cash App application. I don’t want the application — I’m trying to report a card I didn’t order. Being asked to install software in order to tell a company about their own problem is a strange place to start.
So I used the phone number. A human answered and asked what I was calling about.
I explained: I received a card, I didn’t order it, I don’t have an account.
“Well, that is really concerning. What is your name?”
I gave it.
“Cut the card up and throw it away.”
I said I’d like to know what information was used to set the account up. I needed to know whether this was identity theft — whether I should be locking my credit. She offered to connect me to a specialist.
The specialist came on.
“This is really concerning. What is your name?”
I gave it again.
“We’ll need to ask you a set of questions that you must answer completely to resolve your claim.”
My claim? I received a card I didn’t request. I’m notifying you of it. I’m trying to find out what was given to you.
“Sure, sure — I’m just following my process.”
First question: What is your email address.
I’m not your customer. I don’t want to hand you my personal information.
“That is our process. No email, no help.”
I pointed out what she already had and what she had never asked for. She had my name. She had my phone number. She had never asked for the number on the card sitting in front of me. She had never asked for the address the card was mailed to — the address her own company used.
But my email address was mandatory?
“I can’t do anything else for you without your email.”
I hung up.
Where that left both of us
Cash App is no more aware that a card may be compromised in the wild. No case was opened. Nothing was flagged. The one person who called to tell them something was wrong was turned away for declining to hand over data they had no need for.
I am no better informed about the security of my own identity. I still didn’t know what had been used to open that account.
Nobody won. That is the definition of a defective process.
Three things this should raise for anyone running a support function
1. Inbound fraud reports are intelligence, and you are already paying for them
Somebody picked up a phone, spent twenty minutes of their own time, and tried to hand a company a signal about their platform. That signal costs nothing to collect and cannot be bought. It arrives pre-qualified — a person motivated enough to call is telling you something they believe matters.
It is also a conversion opportunity. I was not a customer. Handle that call well and you have a person with a good story about you. Handle it the way mine went and you have someone writing this.
Every call like mine that ends in a hang-up is a chargeback you may eat later, intelligence you discarded, and a customer you will never acquire.
Nobody won. That is the definition of a defective process.
2. Asking a non-customer for PII inverts the trust model
This is the part that should stop a process designer cold.
I called to report something suspicious. The response was a demand for personal information beyond anything that had ever passed between us. There is no relationship here — no account, no prior exchange, nothing.
Demanding personal data from someone with no relationship to you, as a precondition for reporting a problem to you, teaches them that you are not to be trusted. It is the exact behaviour a social engineer would exhibit. And a caller who has been primed to worry about identity theft — which is why they are calling — is being asked to do the one thing they have just been warned against.
Verification should be proportionate to what is being requested. I wasn’t asking for access, a balance, or a change to anything. I was asking a question about a piece of plastic they mailed to me.
Demanding personal data from someone with no relationship to you, as a precondition for reporting a problem to you, teaches them that you are not to be trusted.
3. A playbook is not the same as knowing what your process does
The specialist wasn’t unhelpful by temperament. She said “this is really concerning” and meant it. She was following a script written for a different situation — a customer disputing a transaction — applied to a case it was never designed for.
That is a defect, not a people problem. Somebody wrote a process that cannot distinguish “my card was used fraudulently” from “I received a card I never asked for.” Those need entirely different handling, and only one of them justifies collecting identity data.
How it actually ended
I eventually worked out where the card came from.
My son is in the Army. We share the same name. He ordered the card and had it sent to the house, and forgot to mention it.
That is the part I’d ask every fraud and support leader to sit with. This was never fraud. And the process still failed — it neither resolved a benign case nor captured a real one.
Look at how close it came to working. Any one of these would have closed it on the spot:
- Ask for the card number, confirm who it was issued to — same name, same address — then ask: “is there anyone else at your residence with the same name?”
- Offer the last three digits of the phone number on the account.
- Offer a masked fragment of the email address on the account.
Every one of those uses information Cash App already held. None of them required a single new piece of data from me.
The wider point
Most fraud programmes are built to detect what attackers do. Far fewer are built to receive what ordinary people tell them.
Those 158,509 mailboxes are the reason this matters beyond one bad phone call. Attackers are already inside consumer inboxes, reading Cash App’s mail, without ever touching a password. The evidence of that sits with the customer — which means the first hint reaching Cash App will often be a person on the phone, not an alert on a dashboard.
When that person calls you, the process should be built to listen.
Mine was built to take my email address.
Most fraud programmes are built to detect what attackers do. Far fewer are built to receive what ordinary people tell them.
Figures measured over a 90-day window to 30 September 2026 from myNetWatchman’s observed criminal activity data.