Making money movement reliable on every channel
Leading Personal Banking features in the Raven personal app: free Raven-to-Raven transfers, transfers to any Nigerian bank, QR Pay, receiving by USSD and scheduled transfers.
- Role
- Product Lead and Mobile Architect
- Company
- RavenPay
- Stage
- Launched
- Team
- 1 product designer, 2 mobile engineers, 1 backend engineer with Legal, Compliance and Operations partners
- Platform
- iOS, Android
- Pillars proven
- Product leadership · Mobile architecture · Quality
TL;DR
- Problem
- Transfers were the most used and most complained-about feature. Users saw failures and unclear “pending” states, and people without data couldn’t receive money at all.
- What I did
- Led the redesign of the transfer flow, rebuilt the mobile transfer module around a clear state machine, and added QR, USSD and scheduled transfers.
- Result
- Transfer success rate rose from 96.1% to 99.3%, median send time fell from 45 s to 12 s, and the user base grew 3x in 18 months.
The problem
For users
- A spinner with no status left people unsure if their money had gone. Many sent it again.
- Typing account numbers for the same people over and over caused mistakes.
- Traders and family members without smartphones or data couldn’t receive from Raven users easily.
For Raven
- Each failed or duplicated transfer cost support time and, sometimes, a reversal.
- Free internal transfers were our growth engine, but only if the experience felt reliable.
EvidenceTransfer issues made up 32% of support tickets; 25% of users dropped off at the confirmation step.
The insight that changed the direction: In payments, perceived reliability matters as much as actual reliability. Users needed to see what was happening to their money at every step.
My role
I owned the money-movement roadmap on mobile and led the mobile engineers who built it.
- 1
Mapped every failure point
With backend and Operations, and grouped failures into user error, bank downtime and timeouts, each with its own fix.
- 2
Redesigned the send flow
Recipient first, recent and saved recipients, account-name check before the amount, and an honest “processing” state with push updates.
- 3
Architected the transfer module
As a state machine (draft, confirmed, processing, successful, failed, reversed) with idempotency keys and status polling plus push.
- 4
Added new channels
QR Pay (scan and send), receiving by USSD for people without data, and scheduled transfers for rent and bills.
- 5
Introduced a bank-health indicator
So users knew when a destination bank was slow before they sent.
- 6
Set up automated end-to-end tests
For every money path, success and failure, as a release gate.
Key decisions and trade-offs
| Decision | Why | What we gave up |
|---|---|---|
| Check the account name before the user enters an amount | Catches wrong accounts early, before money is at risk | One extra network call per transfer |
| Show an explicit “processing” state with push updates instead of a spinner | Honest status stops duplicate sends | More states to design, build and test |
| Launch USSD for receiving before sending | Reaches people without data; sending by USSD carried higher fraud risk and compliance work | Sending by USSD was deferred |
| Keep Raven-to-Raven transfers free | Drives network growth: every new user brings others | Fee revenue on internal transfers |
| Scheduled transfers limited to daily, weekly and monthly | Covers rent and bills; simpler retries on failure | No fully custom schedules |
How it was built
- Mobile
- The transfer module is a self-contained feature with a state machine, so every screen reflects one source of truth about where the money is.
- Reliability
- Idempotency keys on every send, retry with back-off on network loss, and safe resumption if the app is closed mid-transfer.
- Security
- PIN or biometric confirmation, server-side limits and fraud checks, and deep links validated for QR payments.
- Quality
- Contract tests against a mocked payment switch, end-to-end tests on a device farm for send and receive (including failures and reversals), and no release without a green money-path suite.
- DraftRecipient first; name checked before the amount.
- ConfirmedPIN or biometric. Idempotency key attached.
- ProcessingHonest status, by polling plus push. Safe to resume if the app closes.
- Successful“Money sent” notification.
- FailedGrouped as user error, bank downtime or timeout, each with its own fix.
- ReversedFunds returned; the user is told.
Send: recipient first
Send money
Account number0123456789
Tunde Bakare · Account name confirmed
Bank healthDestination bank responding normally
Amount₦50,000.00
Processing, with honest status
Transfer · ₦50,000.00
- Confirmed with PIN
- Sent to the destination bank
- Waiting for the bank to confirm
- Delivered
You can close the app. We’ll send a notification when it lands. Don’t send it again.
Notifications
Results
-
96.1% → 99.3%
Transfer success rate
-
45 s → 12 s
Median time to complete a send
-
−60%
Duplicate-send support tickets
-
3x
User base
Blue: my team’s work. Black: feature- or product-level, shared with others.
Reflection
What I’d do differently
Instrument the old flow before redesigning it. We lost 3 weeks adding analytics mid-project to prove the baseline.
What it taught me
In payments, the waiting moment is the product. The “processing” screen did as much for trust as the success rate did.