Unifying the Global Money Movement Rails
How we reduced customer support tickets by 50% by abstracting banking infrastructure complexities (SWIFT, ACH, SEPA) into a user-centric "Single Send" experience.
The Challenge: High Stakes, Low Trust
In the world of international finance, trust is the currency. Our users ranging from migrant workers to high-net-worth individuals faced a fragmented experience when moving money across borders.
Taking 3-5 days for settlement with zero visibility into the transaction status created massive anxiety, leading to a 50% call volume for "Where is my money?" queries.
Business Goal
Reduce support costs and increase retention by creating a transparent, instant, and rail-agnostic money movement experience.
Legacy Experience Audit
- Total "Black Box" (No status updates)
- Hidden Intermediary Fees ($25-$50)
- Complex "Banking Jargon" (IBAN, BIC, SWIFT)
- Zero Error Recovery (Fail = Money stuck 10 days)
We noticed a 24% drop-off at the "Select Transfer Type" screen. To understand why, I facilitated a "Stakeholder vs. User" Workshop.
Discovery Phase
Understanding "The Bleed"
Activity 1: The Affinity Wall
"I don't know the difference between ACH and Wire. What if I pick the wrong one and lose money?"
"Why does it feel like I'm filing taxes just to send $50?"
"Routing Number? Swift Code? I just have their email address."
"I use CashApp because it just asks 'How much?'. I want that here."
"Just make it fast. I'll pay extra."
Heuristic Evaluation (Nielsen's 10)
System provided zero feedback during the 3-5 day settlement window. Users felt the money had "vanished".
Used terms like "IBAN", "SWIFT", and "BIC" without explanation, confusing non-expert users.
No validation on input fields allowed users to send money to invalid account numbers, causing failed transfers.
Data Validation: Quantifying the Friction
We cross-referenced the qualitative feedback with analytics. The results were shocking: Complexity was a bigger blocker than Fees.
- 45% dropped off due to "Confusion" (User Testing).
- Only 15% dropped off due to "Cost".
Ideation Phase
Brainstorming the "Rail-Agnostic" Flow
How might we hide the banking complexity while keeping the compliance flexibility? We used the "Crazy 8s" method to sketch solutions.
Sketch Idea: "The Magic Input"
"The system should decide the rail (ACH/Wire) based on the amount."
The "Aha!" Moment
We realized we didn't need to ask the user how they wanted to send money. We only needed to ask When they needed it to arrive.
The New Logic
IF (Amount < $5000) -> Use P2P (Instant)
IF (Amount > $5000) -> Use Wire (Same Day)
ELSE -> Use ACH (Free)
The Solution Architecture
Rail-Agnostic Routing Engine
To solve the "Mental Model Mismatch", we inverted the control flow. Instead of asking users to choose a rail (Wire vs ACH), we built a middleware logic that selects the best route based on specific constraints.
-
1. Algorithmic Selection
Engine checks: Amount > $5k? Is it a weekend? Is destination eligible for Instant P2P?
-
2. Compliance Handshake
Real-time sanctions screening (OFAC) happens before the user hits submit, preventing stuck funds.
// Smart Routing Logic
function getBestRoute(amount, urgency) {
if (urgency === 'instant') {
return RTP_NETWORK; // Real-Time Payments
}
else if (amount > 5000) {
return SWIFT_WIRE; // High Value Protection
}
else {
return LOCAL_ACH; // Lowest Cost
}
}
The Action
3-Phase Discovery & Design
Phase 1: Discovery & Alignment
I orchestrated a 3-phase discovery and design process to de-risk the solution.
Assumptions Mapping
I gathered Product and Engineering to map out what we thought users knew about banking rails vs. reality.
Outcome
Stakeholders overestimated user literacy. We agreed to hide technical terms (ACH/Wire) and replace them with "Standard" and "Instant".
Competitor Benchmarking
Competitors (Wise, Revolut) don't make users choose rails. They ask "Who?" and "How much?" first.
- Used data to get buy-in
- Validated flow restructure
Phase 2: Defining the Mental Model
Activity: Open Card Sorting (Remote via Maze). I asked 30 participants to group 20 distinct transaction scenarios.
Outcome
Users grouped by Relationship (Family vs. Business) and Urgency, never by technology. This validated the decision to remove the "Select Transfer Type" screen entirely.
Phase 3: Accessibility-First Design
The "Smart Routing" Logic: I designed a Progressive Disclosure interface. We only reveal complexity if necessary. The system defaults to the cheapest option, allowing users to toggle to "Fastest" if needed.
WCAG 2.1 AA Implementation
Instant Transfer Unavailable
We can send this via Standard delivery instead.
The Design
Optimized for cross-border transactions
Send funds across borders with real-time exchange rates and no hidden fees.
- Transparency and security.
- By mentioning "initiation to deposit," we provide a clear roadmap of the money's journey.
The Result
Impact & Verification
"Select Transfer Type" drop-off eliminated.
Saved ops team effort approx 20 hours/week.
Design system components adopted widely.
Support Volume Impact
What Users Said
"Finally! I don't have to Google 'what is an IBAN' every time I send money home. It just works like Venmo now."
"The instant transfer option saved me when I had an emergency. Worth every penny for the speed."
"As a support agent, my life is so much easier. I can see exactly where the money is and tell the customer confidently."
Lessons Learned
Perceived Performance > Actual Performance
Engineering pushed back on "Smart Routing" due to 800ms API latency. I compromised by proposing "Skeleton Loaders" and "Optimistic UI" updates, which kept the perceived friction at zero while the backend crunched the numbers.
Impact of "Plain Language"
Replacing "ACH" with "Standard delivery (1-3 days)" reduced cognitive load more than any visual change. It taught me that copywriting is the most high-leverage UX tool in fintech.