Case Study · Fintech · Decision-Support UX

SafeSpend

A contextual spending review system that helps users pause and reflect before high-risk financial decisions.

Role Product Designer
Timeline 3 Weeks
Domain Fintech · Interaction Design

Most fintech products minimize friction.
This one adds it — selectively.

Routine payments should be fast. But some transactions — unusually large amounts, unfamiliar payees, late-night spending — carry higher risk of regret or fraud. SafeSpend is a design exploration into contextual spending review: a system that surfaces relevant financial context at the moment of decision, without blocking or moralizing.

⚡
What fintech optimizes for
Faster payments · Seamless checkout · One-click EMI activation · Increased conversion rates · Frictionless transactions
⚠️
What this inadvertently enables
Impulsive spending patterns · Hidden debt accumulation · Scam payment approvals · Subscription leakage · Financial regret
SafeSpend introduces a contextual review layer between user intent and financial commitment — not to block transactions, but to create a meaningful moment of reflection at high-risk spending points.

Transaction speed ≠ decision quality

Most fintech products are optimized for transaction completion, not decision quality. Two patterns illustrate this clearly.

Real-World Example 01

Deceptive EMI Design

A user wants to purchase a ₹78,000 smartphone. The checkout screen anchors their attention on one number: ₹3,249/month. Everything else — total repayment, processing fees, stacked debt — is either hidden or minimized.

UI Element
Typical Fintech
SafeSpend
Primary CTA
✗ Large EMI button only
✓ Full repayment breakdown
Cost framing
✗ "No Cost EMI" badge
✓ Debt impact visualization
Checkout flow
✗ Fast, single-step
✓ Financial stress indicator
Existing debt context
✗ Never shown
✓ Stacked burden timeline
User intent
✗ Reduce hesitation
✓ Surface informed choice
Real-World Example 02

UPI Scam Approval

Users frequently approve fraudulent payment requests because the interfaces feel familiar, approval flows are fast, and warnings are generic. Current systems verify authentication — but rarely evaluate behavioral risk. The interface looks legitimate, so the user assumes it is.

Understanding the decision gap

The research goal was to understand why users ignore financial warnings, how impulsive spending happens, what makes scam interfaces believable, and where financial regret originates.

12
User Interviews
84
Survey Responses
7
Fintech Apps Audited
3
Core Behavior Patterns
01

Users Think in Monthly EMIs, Not Total Cost

Most participants evaluated affordability through monthly payment amount and short-term convenience. Very few spontaneously calculated total repayment, stacked debt impact, or projected future financial stress. The monthly frame is cognitively cheaper — and interfaces exploit this.

02

Generic Warnings Are Functionally Invisible

Alerts like "Are you sure?" were dismissed almost instantly. Users responded meaningfully only when systems explained why the action was risky, what impact it might create, and how confident the system was in its assessment. Context transforms a warning from noise into signal.

03

Emotional Spending Has Predictable Patterns

Impulsive spending was not random. It concentrated around late-night hours (10 PM – 1 AM), immediately after stressful events, during urgency sales, and in the days following salary credits. These patterns are detectable — and therefore interruptible.

Late-Night Spending Spike
Impulsive transaction frequency by hour of day
6 AM 12 PM 6 PM 10 PM 1 AM
Low risk window
Moderate activity
Elevated impulsivity
Peak risk zone
How might we surface relevant financial context at the point of a high-risk payment — without adding friction to routine transactions or making users feel judged?

A spending review system, not a payment blocker

SafeSpend evaluates transaction timing, spending patterns, merchant context, and affordability signals — then determines whether a review prompt is warranted, and at what intensity. Low-risk transactions proceed uninterrupted. The system intervenes only when multiple signals indicate a user may benefit from pausing to reconsider.

The system uses a combination of behavioral and transactional signals to decide whether a review prompt is warranted. No single signal triggers intervention — the logic requires multiple signals to align. Recommendations are probabilistic, not definitive. Users always retain full control.

Timing signals
Unusual purchase hour · Transaction outside normal window · Rapid spending bursts
Amount signals
Significantly above monthly average · Large first-time amount to new payee · EMI commitment vs current balance
Context signals
Unfamiliar merchant category · Unverified UPI handle · Urgency language in payment note
Limitation: Pattern detection works well at the extremes — clear anomalies and clear routine. The middle ground (moderately unusual transactions) is where false positives are most likely and threshold calibration matters most.
Feature 01

High-Risk Spending Review

A user attempts an ₹18,000 sneaker purchase at 12:14 AM — outside typical spending hours, and after already exceeding their monthly discretionary average. The system detects a combination of timing, amount, and budget signals, and surfaces a contextual review prompt rather than proceeding silently.

  • Projected balance after purchase
  • Monthly spending comparison vs. average
  • Financial pressure indicator
  • Optional "wait 24 hours" reminder
  • Full user control — never a hard block
Spending Intervention
Purchase amount
₹18,000
Nike Air Max — Late Night Purchase
⏰ 12:14 AM · Outside typical spending hours
Financial Impact
Balance after purchase₹4,320
This month vs. avg+148%
Budget statusExceeded
Spend vs. Monthly Avg+148%
⏳ Remind me tomorrow
Continue with purchase
Feature 02

Scam Pattern Detection

The review logic analyzes UPI handle patterns, transaction urgency signals, payment amount anomalies, and known scam pattern signatures. When multiple signals align, the interface explains the specific reasons — not just triggers a generic warning.

  • Risk signals made visible with plain explanations
  • "Why this review appeared" transparency
  • Recommended action, not forced block
  • Grounded in real-world scam taxonomies
Scam Warning
⚠️
This payment looks unusual
We noticed a few things worth reviewing
UPI IDrefund.help@ybl
Amount₹4,999
Message"Urgent refund needed"
Signals detected 3 of 3
⚠ Urgency language detected
⚠ Unverified merchant ID
⚠ Matches scam database
I understand the risk — proceed
Extended Scope — Explored, Not Primary

EMI Transparency & Subscription Review

Two additional flows were sketched but kept out of the primary design focus: a full EMI repayment breakdown (surfacing total cost, not just monthly amount) and a recurring subscription review screen (flagging inactive or duplicate subscriptions). Both are coherent extensions of the same review logic — but including them as full features risks diluting the core use case. They're documented here as directions, not deliverables.

What makes this hard to get right

Any system that adds friction to payments carries real risks. These constraints shaped every design decision — and would need to be explicitly managed in a production implementation.

⚠️
False Positives
Legitimate payments incorrectly flagged erode trust quickly. A user interrupted during a routine transaction to a known contact will disengage from the system — and potentially the app.
🔔
Interruption Fatigue
Warnings repeated too frequently become ignored. The system's value depends on its ability to be quiet most of the time — which requires precise, high-confidence thresholds.
⏱️
Latency & Urgency
Users making urgent, time-sensitive payments (bill deadlines, emergency transfers) may be genuinely harmed by a review delay. The system cannot treat all high-amount transactions identically.
🔒
Privacy Sensitivity
Detecting spending patterns requires behavioural monitoring at the transaction level. This raises data consent and privacy questions — especially in a market where financial data sensitivity is high and user trust in apps is fragile.
⚖️
Financial Autonomy
Users have the right to make their own financial decisions, including risky ones. A review system that feels paternalistic or judgmental will be rejected — regardless of how accurate it is.
📋
Regulatory Sensitivity
Intervening in payment flows in India has regulatory implications under RBI guidelines. Any production version would need to operate within those constraints — and avoid language that implies guaranteed fraud prevention.

When the system gets it wrong

No risk detection system is error-free. Understanding what breaks — and how the system should respond — is as important as designing the happy path.

Scenario: A user is transferring ₹40,000 to a family member they haven't paid before. The amount is large, the payee is new, and the transfer happens at 11 PM — all three signals trigger the high-risk review flow. But this is a completely legitimate, urgent payment.
✕
What breaks
The user is interrupted during an urgent transfer. The review flow adds 30–60 seconds. If the tone feels accusatory ("This looks suspicious"), the user feels wrongly judged. They may lose trust in the system — or the app entirely.
→
Mitigation logic
The review should explain specific signals calmly ("New payee · Large amount · Unusual time"), not assert fraud. The primary CTA should be "Continue" — not "Cancel." Override should be one tap, not buried. Users should never feel blocked, only informed.
Fallback behavior
If a user dismisses the same review type 3+ times in a short period, the system should reduce sensitivity for that signal — treating repeated override as an implicit "I understand this risk." Warning fatigue is a failure state that the system itself should detect and adapt to.

Honest tensions, deliberate decisions

Real product work means navigating competing priorities. These tradeoffs shaped every design decision in the system.

Protection vs Conversion

Aggressive warnings reduce transaction completion, EMI adoption, and platform revenue.

Decision: Adaptive intervention thresholds — not blanket blocking of risky actions.
Accuracy vs Alert Fatigue

Too many alerts erode user trust and train users to dismiss everything.

Decision: Only high-confidence risks trigger full intervention flows. Lower-confidence signals remain passive.
Safety vs User Control

Overprotective systems feel paternalistic and manipulative, driving disengagement.

Decision: Users retain final decision authority — except when fraud confidence is extremely high.

Constrained intentionally

The project scope was deliberately narrowed to one primary problem: high-risk spending interruption and review. A concept exploring four features simultaneously risks credibility — so secondary flows were documented but excluded from the primary design focus.

Primary Focus (V1)
Contextual spending review prompts
High-risk transaction detection logic
Scam pattern signal surfacing
Deferred / Exploratory
EMI transparency flow
Subscription leakage detection
AI financial coaching
Cross-bank integrations

What good looks like

Without deployment or user testing at scale, these represent intended design goals — the measurable outcomes a functional version of this system would need to achieve to be considered successful. They are conceptual KPIs, not validated results.

Risky Payment Approvals
↓ Reduction
Fewer high-risk transactions completing without review
Warning Engagement
↑ Read rate
Users reading context before dismissing, not instant skip
False Positive Rate
↓ Minimised
Legitimate payments not interrupted unnecessarily
Post-review Cancellations
↑ Tracked
Users choosing to cancel after seeing review context
Alert Fatigue Signal
↓ Controlled
Repeat-dismissal rate tracked to detect warning burnout
User-reported Trust
↑ Maintained
System feels helpful, not paternalistic or intrusive
Transaction speed → Decision quality

A focused product concept, not a complete system

SafeSpend is a design exploration into contextual spending review — not a deployed product. The core question it explores: can a fintech product add friction selectively and helpfully, without damaging user trust or blocking legitimate payments?

The most important constraint discovered: the system's credibility depends entirely on how rarely it fires, and how clearly it explains itself when it does. An over-eager review system becomes noise. A well-calibrated one becomes a tool users trust.