← Back
Encouraging Zelle users to report potential scams

Designing scam reporting flows that collect useful fraud data without pressuring users.

IMPACT
14M
Zelle users reached
2
scam reporting flows designed
1
new fraud data pipeline created
OVERVIEW
Timeline
3 months
Problem
Users who canceled Zelle payments after seeing scam warnings had no way to report the potential scam. The bank was losing valuable signal that could improve fraud detection and prevent future scams.
Users
All consumer segments using Zelle (14M users).
Primary goal
Allow users to report potential scams when canceling a payment.
Secondary goals
Create a data feedback loop so the fraud team can refine risk rules and update scam warnings based on real user reports.
Constraints
Reporting must be optional. Messaging cannot be alarming or make users feel obligated. Must work within two distinct cancellation flows with different risk levels.
MY ROLE
Owned all UX copy
Wrote the content for scam protection tips, purpose of payment disclosures, cancellation modals, and report overlays across both flows.
Defined reporting options with the fraud team
Collaborated to build the category set for the purpose of payment disclosure. Chose language that distinguishes legitimate payments from common scam patterns without leading users toward a specific answer.
Influenced the flow structure
Made the case for keeping scam reports optional rather than required, so the experience feels helpful rather than intrusive at a moment when users may already be on edge.
KEY DECISIONS
Writing purpose of payment categories that surface scam patterns

When a user sends money to a recipient flagged as high risk, a full-screen modal requires them to disclose the purpose of payment before continuing. I worked with the fraud team to define the options. Legitimate reasons (paying a friend or family member, a corporation, a bank, or a government entity) sit alongside categories that map to common Zelle scams (marketplace purchase not yet received, security deposit for a vacation rental). The language needed to be neutral enough that users with legitimate payments wouldn't feel accused, while still capturing the signal the fraud team needs to identify patterns.

Purpose of payment disclosure modal with radio button options
Framing scam protection as a checkpoint, not a warning

When a user adds a new recipient and tries to send money immediately, they see a full-screen modal with scam protection tips. The tone here was critical. Too aggressive and users feel like the bank is accusing them of something. Too soft and the tips get ignored. I wrote the content as a quick checkpoint: clear, factual, and non-judgmental. Users acknowledge they are not being scammed and continue, or they cancel.

Scam protection tips modal for new recipients
Encouraging reports without requiring them

Both flows converge on the same question after cancellation: was this a potential scam? The overlay needed to encourage users to report without making them feel obligated. Some users cancel for reasons that have nothing to do with fraud, and they should not feel pressured to file a report. I wrote the messaging to acknowledge that cancellation could mean anything, then gently surface the option to report if the user believes the recipient was running a scam. The goal was to collect real signal without polluting the data with reports from users who just changed their mind.

Payment to flagged recipient
Report recipient overlay after canceling a flagged payment
Payment to new recipient
Report overlay after canceling a payment
THE OUTCOME

The scam reporting flows shipped to all 14M Zelle users, giving the bank its first structured channel for collecting scam signal directly from the cancellation experience. The data feeds back to the fraud team to refine risk rules and update the scam warnings users see, creating a loop where each report makes the next warning more accurate.

© 2026 Brandon Fischetti