Shipped P2P Feature Advancing Trust & Safety
Zelle® had no native way to block an unwanted sender. Fraud complaints routed through Financial Institutes(FIs) customer service, making it an expensive, slow, and user-hostile process. I designed an in-app block flow that works across 2,000+ participating FIs, balancing user autonomy with FI compliance requirements. Shipped in 2026, with key results of fraud escalations fell measurably in network FIs.
01
PROBLEM
Users Are Missing Protection
When a Zelle® user received unwanted payment requests, e.g. from an ex, a scammer, or a mistaken sender, the only recourse was to contact their FI's customer service, revealing a missing UX component for a mature payment app.
The underlying tension: Zelle® is a network product. Any block feature had to work across 2,000+ participating FIs, each with different established design systems, information hierarchy and compliance requirements.
What Competitors Get Right
I worked with a UX researcher to analyze the blocking UX of Venmo, PayPal, and Cash App. Key patterns found:
Blocking is typically one-click from transaction or profile views
Blocked users cannot send or request funds
Blocking is reversible
Apps differ in whether blocked users are hidden or remain visible
This helped me define Zelle®’s unique design principles within a bank-integrated environment.
A harassing ex-partner
A harassing ex-partner used small-value transactions to send a memo to Zelle® users.
A well-meaning grandmother
A well-meaning grandmother kept sending $100/month despite repeated requests to stop.
02
STRATEGY
The Puzzle: Customer ID vs. Token
Zelle® transactions are based on a tokenized identity system. A user’s phone number or email (Token) is mapped to a backend Customer ID, which varies per FI and isn’t visible to users.
Users typically recognize unwanted senders by transaction history, with some via contact lists. But contact lists show Tokens while transactions show Customer IDs, meaning they are different by nature.
Solution: Block from Activity Only
I iterated the UX proposals multiple rounds as Product and Development teams discover new network limitations. I finally decided to prioritize blocking from the Activity Details, where users can confidently identify unwanted senders. This means the feature will block at Customer ID level only, not at token level.
I intentionally avoided technical terms like “Token” and “Customer ID” in the interface, keeping the UX simple and emotionally intuitive. Meanwhile, I owned walkthrough sessions with each FI to communicate how the UX guidelines and the APIs work together.
03
EXECUTION
Entry Points
I placed the "block Zelle® recipient" entry point directly from Activity Details, so users can take action when they notice unwanted senders.
To allow users manage the blocked contacts, I created a new “Blocked Contacts” section under Preferences, which is in parallel to the Zelle® recipient list. The items are Customer IDs vs. Tokens by nature, hence living in separate sections.
Future-Ready Design for a Smarter Network
As Zelle®’s platform evolves to unify Tokens and Customer IDs, I'd add the following to this feature:
Enable blocking from Zelle® recipient list, meaning blocking at Token level.
Synchronize blocking status across all surfaces
Support dual-mode blocking (Token + Customer ID)
This roadmap ensures the feature is scalable, intuitive, and robust as the network matures.
Financial institutes met UX compliance
BACK TO