Unit 4.case
Case Study: Digital Wallet Fraud Controls
Balancing UX and Security
Learning Objectives
By the end of this case study, you will be able to:
- ✅ Analyze the tension between user experience (UX) and security in e-commerce.
- ✅ Identify multi-layered fraud detection techniques used by digital wallets.
- ✅ Evaluate the role of policy and user education in a security framework.
- ✅ Connect theoretical concepts from Unit 4 to a real-world implementation.
The Challenge: A Surge in Fraud
Illustrative/composite case outcomes; no named provider evaluation supplied. The 60% / three-month claim is not verified.
The Problem ⚡
A leading digital wallet provider faced a sharp increase in successful fraud attempts.
- Social Engineering Attacks
- SIM-Swap Scams
- Account Takeovers (ATO)
The Dilemma 🎯
How to stop fraudsters without frustrating legitimate users?
This connects directly to our study of the Threat Landscape (Ch. 4.2).
Activity: Identify the Fraud Type
Fictional scenarios, not reports of breaches at named providers. Fraud mechanisms overlap; choose the most direct mechanism.
Read each scenario and select the correct fraud type, then check your answers.
🎬 Watch: Protect Your Number
Three Separate Trust Points
Control 1: Dynamic Risk Scoring
Key Concept (Ch. 4.3): Instead of a single rule, the system calculates a risk score for every transaction in real-time.
🔍 Inputs for Scoring
- Transaction Amount
- Device Fingerprint
- IP Address & Geolocation
- Transaction Velocity
- User History
🚦 Risk-Based Action
- Low Risk: Seamless approval.
- Medium Risk: Step-up authentication.
- High Risk: Block & flag for review.
Simulation: Dynamic Risk Score Calculator
Illustrative score, not a fraud probability or a provider’s actual rule. Hard limits cannot be waived by an OTP.
Adjust the transaction parameters below and see the risk level update in real time.
1,000
1
A Risk Score Is Not Permission to Break a Limit
- Hard limit: a legal, contractual or account-tier restriction. If a transfer exceeds it, apply the authorised limit/upgrade process; an OTP cannot waive it.
- Risk threshold: an internal trigger for challenge, delay, review or blocking. This can be tuned with evidence.
- Velocity: many small transfers can matter as much as one large one. Consider time window, total value, recipient changes and the customer's history.
- Known device ≠ safe transaction: malware, coercion or an already-compromised session can still create risk.
The classroom score is a rule-based index, not a calibrated chance of fraud. A score of 60/100 does not mean a 60% probability.
Payment Velocity
Control 2: Modernizing Authentication
The provider moved away from vulnerable SMS One-Time Passwords (OTPs) for high-risk actions.
Old Method: SMS OTP
- Vulnerable to SIM-swap
- Can be intercepted
- Relies on telco security
New Method: Device Binding
- Links account to a specific, trusted device.
- Uses secure push notifications for approval.
- Much harder for attackers to bypass.
Repeated Prompts Are Not Proof of Identity
Illustrative scenario: your phone repeatedly asks you to approve a login you did not start. Someone calls claiming “support” and asks you to approve it to stop the alerts.
- Push fatigue: repeated approval prompts can pressure a user into accepting an attacker's session. More prompts are not always more security.
- OTP social engineering: sharing a one-time code can authorise an attacker. A code must not be read to an unsolicited caller.
- Design response: rate-limit prompts, show useful transaction context and provide a clear “not me” route. These are proposed controls, not claims about a named wallet.
Safe user response: reject the unexpected prompt and contact the provider through its official app or a separately verified channel.
🎬 Watch: Death by a Thousand Prompts
Context Before Approval
Decision Tree: Which Authentication Response?
Statutory, contractual and KYC/account limits cannot be overridden by an approval prompt.
Walk through a transaction scenario step by step to determine the correct authentication outcome.
Lost Phone: Recovery Without a Shortcut
Pair task: the legitimate customer lost the bound device. “Approve on your old phone” cannot be the only recovery route.
- Offer an independently verified recovery process; a phone number alone is weak evidence if SIM swap is suspected.
- Revoke affected sessions and old device credentials; re-enrol the replacement device through the authorised process.
- Notify the customer through available trusted channels and monitor sensitive changes or unusual transfers.
- Explain temporary restrictions, review options and expected next steps. Avoid a vague permanent lockout.
Device binding is not merely recognising a fingerprint or sending a push. Secure enrolment, keys, revocation and recovery determine its strength.
Secure Device Re-enrolment
Control 3: Policies & Governance (Ch. 4.4)
Technology alone isn't enough. The solution required strong internal policies.
- Tiered Transaction Limits:
- Limits based on user's KYC (Know Your Customer) verification level.
- Higher verification = higher limits.
- Cooling-Off Periods:
- A mandatory waiting period after sensitive profile changes (e.g., changing phone number or password).
- Prevents immediate fraudulent fund transfers after an account takeover.
Control 4: The Human Layer
Recognizing that social engineering bypasses technical controls, the wallet provider focused on user education.
📢 Banners
Prominent warnings about common scams displayed within the app.
💡 In-App Tips
Contextual advice during checkout or profile changes.
🚨 Rapid Takedown
A streamlined process for users to report scams, enabling fast response.
Activity: Match the Control to the Threat
SIM swap is carrier number reassignment, not necessarily SIM cloning. Proposed controls are not claims about a named wallet.
Click a Threat, then click the Control that best mitigates it.
Threats
Controls
Global Parallel: M-PESA and Impersonation
- Kenya, Safaricom: its public fraud-awareness advice warns about people impersonating support and asking for an M-PESA PIN or personal information.
- It advises customers not to follow unknown callers' instructions and to verify with known contacts before sending money.
- Nepal application: write a contextual warning for a suspicious transfer: “Did a caller ask you to send this money? Stop and verify independently.”
- Boundary: this is a sourced education parallel—not evidence that M-PESA, eSewa or Khalti uses the classroom risk weights, device-binding design or cooling-off period.
Do not copy Kenyan phone numbers or reporting instructions into a Nepal user journey; use the relevant provider's verified local channel.
M-PESA Agent, Nairobi
The Outcomes: Measurable Success 📊
Illustrative/composite case outcomes; no named provider evaluation supplied. The 60% / three-month claim is not verified.
Security Wins
60% reduction in fraud loss rate within the first 3 months.
- Fewer support tickets related to fraud.
- Clearer internal runbooks for handling security incidents.
User Experience Preserved
Checkout success rates for low-risk transactions remained unchanged.
This demonstrates a successful balance: security friction was only applied when genuinely needed.
Did Fraud Fall—or Did the Denominator Change?
Illustrative figures, not a real wallet report: baseline fraud loss Rs 100,000 on Rs 10 million of payments. Later loss Rs 60,000 on Rs 15 million.
- Baseline loss rate? 100,000 ÷ 10,000,000 = 1%.
- Later loss rate? 60,000 ÷ 15,000,000 = 0.4%.
- What fell by 60%? The loss rate: (1 − 0.4) ÷ 1 = 60%. Absolute loss fell by 40%, not 60%.
- What else should be checked? Legitimate completion, false declines, recovery time, complaints, reporting delays and whether the transaction mix changed.
“Low-risk checkout unchanged” can hide harm to other users. Compare all users and relevant cohorts, not just the easiest transactions.
Losses and Payment Volume
Discussion: When Is Security Friction Justified? (1/3)
Separate illustrative policies: the Rs 75,000/new-device example differs from the calculator; velocity windows and 24-hour cooling-off are not universal rules.
Vote on whether adding authentication friction is worth it for each scenario, then reveal what this case study's system actually decided.
Discussion: When Is Security Friction Justified? (2/3)
Separate illustrative policies: the Rs 75,000/new-device example differs from the calculator; velocity windows and 24-hour cooling-off are not universal rules.
Vote on whether adding authentication friction is worth it for each scenario, then reveal what this case study's system actually decided.
Discussion: When Is Security Friction Justified? (3/3)
Separate illustrative policies: the Rs 75,000/new-device example differs from the calculator; velocity windows and 24-hour cooling-off are not universal rules.
Vote on whether adding authentication friction is worth it for each scenario, then reveal what this case study's system actually decided.
Practical Application: The Nepali Context
Thinking Locally 🇳🇵
Consider popular digital wallets in Nepal like eSewa or Khalti.
- How do they implement device binding? (e.g., login alerts, trusted device lists)
- What are their KYC tiers and how do they affect transaction limits?
- Have you seen in-app educational banners warning about lottery scams or fake social media offers?
- This case study's principles are directly applicable to securing Nepal's growing digital payment ecosystem.
Tabletop: Suspicious Transfer, Real Customer
Illustrative case: a new device appears, the phone number changes and several unfamiliar recipients are added. The customer says the SIM stopped working. In pairs, propose the first three response steps.
- Contain: flag the account and apply authorised protective restrictions; preserve transaction, device and change-event evidence.
- Verify: contact the customer using the approved recovery route; do not rely only on the newly changed number or ask for an OTP.
- Recover and review: revoke compromised sessions, coordinate with the provider/carrier, explain next steps and check related suspicious activity.
Name an owner, escalation route and customer communication step. Do not promise that a completed transfer can always be reversed.
Key Takeaways & Lessons
Lesson 1: Defense-in-Depth is Critical
A single control (like just having a password) is insufficient. Layering technical and policy-based controls creates a much stronger defense.
Lesson 2: Security Must be Adaptive
Fraud tactics evolve. Security thresholds and rules must be continuously tuned based on market behavior and emerging threats.
Lesson 3: Don't Forget the User
User education is a vital security layer. An informed user is less likely to fall for social engineering, which no technology can fully prevent.
Case Practice 📝
- Which security threats from Unit 4 appear in this case? Explain how each attack works.
- Why is SMS OTP weak against SIM swap attacks, and how does device binding help?
- Explain risk-based (step-up) authentication. How does it balance security and convenience?
- Why does the case stress customer education even after technical controls are added?
- Draft three short in-app warning messages the wallet could show its customers.
Revise the answers in the full note.
Sources & Media Credits
- SIM-swap, velocity, approval, re-enrolment and fraud-rate diagrams: made for IT204, CC BY 4.0.
- M-PESA agent, Nairobi: Fiona Graham, CC BY-SA 2.0 (Wikimedia Commons).
- Videos: WION; Keytos Security.
- Image 5: source — CC BY-SA 2.0, Fiona Graham
- Clip 1: source
- Clip 2: source
- Safaricom: fraud awareness
Thank You
This case study illustrates the dynamic interplay of technology, policy, and user behavior in securing e-commerce platforms.