Fraud Alarm
- Status
- Field report v1
- Timeframe
- 1 month
- Role
- Head of Product Design
- Team
- 1 designer, 1 PM, 4 developers, risk, CRM/support
- ~15 min → <3 min
- Response window
- 39%
- Fraud reports moved directly into the app
- 2
- Entry points: transaction detail + Security Centre
- 6
- Automated protection actions
Fraud was being handled like support.
When users noticed suspicious activity, they often had to search for the customer-care number, call the helpline, navigate IVR, and wait for a human agent, all while panicking.
The issue was not just delay. If credentials were already exposed, every minute spent searching, calling, and waiting created another window for additional fraud.
From customer-care escalation to emergency control.
We reframed fraud reporting from “how does the user reach support?” to “how does the bank start protection immediately?”
Fraud Alarm moved the first protective action into the app, then brought CRM/support into the workflow after the emergency sequence had already started.
- Report Fraud on transaction detail page
- Fraud reporting inside Security Centre
- 01Account frozen
- 02MPIN expired
- 03New MPIN sent by SMS
- 04Service request raised with last 24 hours transaction history
- 05CRM team notified
- 06Callback initiated
Place reporting at the point of suspicion
The transaction detail page was the most likely place users would notice fraud, so the Report Fraud action was placed there.
Create a persistent safety destination
Security Centre grouped safety-related products and conditioned users to return there for fraud and security needs.
Add intentional friction
Swipe, warning, and countdown were added because account freeze and MPIN expiry were high-consequence actions.
Separate fraud from general support
Users who cancelled were shown the normal non-emergency customer-care number, so they were not abandoned.
Filter for fraud-relevant transactions
The emergency path was limited to recent outgoing-money transactions within 24 hours across both entry points.
- Suspicious transaction
- Search customer-care number
- Call helpline
- IVR
- Agent wait
- Explain issue
- Protection begins
- Suspicious transaction
- Report Fraud
- Swipe
- Warning + countdown
- Protection sequence
- Live checklist
- Callback/recovery
The Fraud Alarm journey
The full in-app emergency-control experience, from alarm to resolution.
Fraud Alarm reduced the response window from approximately 15 minutes to under 3 minutes.
- Definition
- Time from suspected fraud transaction to completion of Fraud Alarm protection sequence.
- Source
- Transaction logs + customer-care logs.
- Attribution
- Primarily attributable to Fraud Alarm because the workflow replaced helpline dependency with an in-app one-swipe emergency action.
- Supporting signal
- 39% of fraud reports moved directly into the app without speaking to anyone.
As Head of Product Design, I identified the fraud-response gap through support-call analysis, reframed the problem as emergency control, directed the UX strategy, and aligned product, risk, CRM/support, and engineering.
- Identified the delay before protective action
- Framed the emergency-control hypothesis
- Directed entry-point and friction strategy
- Aligned product, risk, CRM/support, and engineering
- Used post-launch behavior to refine eligibility