Real-time fraud response for 1,000+ Credit Union members
Tags: Fintech · Mobile · UX Research · Flow Design
CONTEXT
Designing real-time fraud response for thousands of credit union members across the US
Fiserv builds the financial technology infrastructure that powers small and mid-size credit unions — the kind of institutions where members have banked for decades, where trust is personal, and where a single bad experience can break a relationship that took years to build. In March 2020, I joined the team working on the member-facing mobile hub — a white-label platform that gave credit unions a digital presence: account management, transactions, alerts, and support, all in one app. My focus was a feature that didn’t exist yet but was badly needed: Fraud Alert.
MY ROLE
UX Designer — Fraud Alert Feature Lead
Focus
Edge case mapping, flow
design, customer-facing experience.
Team
Product, engineering, credit union stakeholders.
Platform
Mobile (iOS & Android).
Timeline
March 2020.
THE PROBLEM
When fraud happened, members were on their own
Credit union members are disproportionately vulnerable to fraud. Many are older, live in rural or underserved areas, and have limited experience navigating digital financial tools. When unauthorized purchases appeared on their account — stolen card data, account takeovers, unfamiliar recurring charges — their only option was to call the credit union.
That meant: hold times. Business hours. Explaining the situation twice. A card staying active while they waited. Two compounding failures made this worse:
- Members were blind. There was no real-time visibility into suspicious activity. By the time someone noticed something was wrong, the damage was already done.
- Credit unions were reactive. Their internal systems could flag anomalies, but there was no mechanism to loop the member in quickly; no alert, no action, no resolution path inside the app.
The question was: what does a member need to see, feel, and decide in the right order to stop the damage?
MAPPING CASES
The work that happened before any screen was drawn
Fraud is a family of situations that look similar on the surface but require completely different responses underneath. Before I designed anything, I needed to understand the full map.
I worked through every scenario where fraud could realistically surface:
- A card physically stolen and used in-store
- Account credentials compromised, purchases made online
- A recurring subscription charge the member didn’t recognize
- An international transaction on an account that never travels
- A legitimate purchase the member simply forgot they made
For each one, I identified the critical decision points that the design would need to support: Is this actually fraud or a mistake? Has the member already taken action, or are they seeing this for the first time? Is the card still active and exposed, or has something already been blocked?
The insight that shaped everything
The same alert needed to work for a 72-year-old member in a rural community and a 28-year-old checking their phone on the subway. Same stakes. Radically different mental models, digital comfort levels, and emotional states.
That tension between simplicity and completeness, between speed and clarity, became the design’s north star.
DESIGN DECISIONS
Designing to reduce the time between panic and resolution.
Most alert experiences are built around one assumption: the member sees the notification, confirms it’s fraud, and the system takes over. But real fraud doesn’t work that way. Members miss notifications. Cards get auto-blocked before anyone acts. Reports fail mid-submission. Investigations drag on.
The edge case mapping work produced a concrete artifact: a response code system. A set of distinct UI states that adapted the experience to exactly where a member stood in the fraud lifecycle. Each code had its own copy, its own call to action, and its own emotional register.
The card was already handled (Before the member acted)
One of the earliest edge cases surfaced in discovery: what if the credit union’s system catches and resolves the fraud automatically? The member still needs to know, but the last thing they need is an alert that makes them feel like they have to do something when there’s nothing left to do.
This state was designed to reassure first and inform second. The checkmark, the direct headline, the single “Done” exit every element was chosen to lower the member’s heart rate, not raise it. “No action required” is doing a lot of work in three words.
The member confirmed the charges were theirs
When a member reviewed flagged transactions and confirmed they were legitimate, the experience needed to close cleanly; no alarm, no friction, no suggestion that something was still wrong. The card stays active. Monitoring continues quietly in the background.
The copy here was deliberate: “We will continue to monitor your card for unusual activity” closes the loop without being ominous. It tells the member the system is working for them, not watching them.
The member reported fraud (First time)
This is the screen where copy precision mattered most. “Your card ending in 6789 may be temporarily restricted” the word may is not hedging. It’s accurate. At the moment this screen appears, the restriction hasn’t necessarily been confirmed yet. Overpromising a freeze that didn’t happen would be worse than being honest about the uncertainty.
The “Contact us” CTA is primary here — the member just flagged something serious and the fastest path to resolution is a human. “Done” exists but sits secondary, for the member who wants to acknowledge and step away.
The member reported fraud (Card was already restricted)
One word changes. “May be temporarily restricted” becomes “will continue to be restricted.” This is the repeat-state version triggered when a card block was already in place before the member submitted their report.
This distinction exists entirely because of edge case mapping. Without it, a member in this situation would read copy that implied their report triggered the restriction when it was already there. That’s a small inaccuracy that would have created real confusion and real support calls. The design accounted for it.
The investigation is open (The credit union is working on it)
The hardest state to design for is waiting. The member has acted. The system has received the report. But nothing is resolved yet. This screen needed to communicate progress without overpromising a timeline and to give the member somewhere to go if the uncertainty was too much.
“Suspicious activity has been detected on card ending in 6789. Please contact us for further information.” it’s plain, honest, and doesn’t manufacture false confidence. The primary CTA is “Contact us” again, keeping the human channel open. “Done” lets members who trust the process step away without anxiety.
What this system made possible
Five distinct screens. Five different member situations. One consistent visual language — the same header, the same icon treatment, the same button hierarchy — so that no matter which state a member landed in, the experience felt like the same product making a considered decision about their specific moment.
That consistency didn’t happen by accident. It came directly from the edge case mapping: by defining every branch before designing any screen, the response code system could share components while still communicating something meaningfully different in each state.
OUTCOME
What changed when members had control
This project didn’t come with a research phase or measurable post-launch data I could track. The scope was clear from the start: take a defined problem and design a solution that held up under every real condition a member might face.
What I could control was the thinking before the screens. The edge case mapping produced a response code system that covered five distinct member situations — each with its own copy logic, emotional register, and call to action — while sharing a consistent visual language across all of them.
The measure of success here wasn’t a metric. It was whether the design could answer: what does a member need to see, feel, and decide, (in the right order, to stop the damage)? The response code system was the answer.
REFLECTION
What fraud taught me about designing for crisis
This project changed how I think about flows that carry emotional weight. Most UX work happens in a neutral emotional state; a user browsing, comparing, deciding. Fraud happens in a spike. The design can’t assume the member is calm, patient, or willing to read. It has to meet them where they are: scared, confused, and needing to act now.
Edge case mapping was the major part of the work. The happy path was almost the easy part. The real design lived in the branches: what if they don’t recognize the merchant name? What if they froze the card but the charge was theirs? What if they’re on a credit union that has different escalation rules?
Uncovering those branches before a single screen was drawn is what made the feature hold up under real conditions and it’s a habit I’ve carried into every high-stakes design problem since.
Other Projects
