CrossBorda
Cross-Border Payment System
Role
Lead Product Designer
Timeline
2023
Platforms
Web (dashboard + customer-facing)
Status
Shipped
Overview
CrossBorda is a cross-border payout platform built for the complexity of African payment corridors — where compliance requirements, identity verification, and multi-step transaction flows must work together without breaking under operational load. I designed the end-to-end system: from how a business onboards and gets verified, to how they initiate and track payouts in real time.
The Problem
Cross-border payments are structurally complex. You're not designing a simple transaction. You're designing a system that must handle regulatory compliance (KYC, AML screening, jurisdiction rules), identity verification across multiple document types and countries, multi-step approval workflows with real-time status changes, beneficiary management at scale, and failure states — transaction rejections, document failures, webhook timeouts. Most fintech products get one or two of these right. The challenge was designing a system that handles all of them, cohesively, without overwhelming the operator using it.
Constraints
These constraints shaped every design decision:
Compliance-first, not UX-first. Regulatory requirements aren't optional — every flow had to accommodate verification steps that users would prefer to skip.
Non-technical operators. The platform is used by finance teams and operations staff — not developers. Technical complexity had to be invisible at the interface layer.
Incomplete data states are normal. In cross-border payments, "pending" is a legitimate long-lived state. The design had to handle ambiguity without creating user anxiety.
Scalability from day one. The beneficiary system needed to support both one-off and recurring payouts without a rebuild as the platform grew.
My Role
I owned the product design end-to-end: defined the information architecture, designed the KYC onboarding system, architected the beneficiary management system, designed the payout initiation and tracking flows, defined the notification and status update system (connected to webhook events), and built and maintained the component library.
Approach
I started with the failure states, not the happy path. In payments, the UX of things going wrong is more important than the UX of things going right. A failed transaction that gives a clear reason and a clear next action retains trust. A failed transaction with a generic error destroys it. So the first thing I mapped was every failure condition — then I built the happy path around them. For the beneficiary architecture, I designed around the assumption of scale: the data model needed to support different payout methods from day one.
Key Decisions
Decision 1
Progressive KYC Over Front-Loaded Verification
Asking for all identity documents upfront creates high drop-off before the user sees any product value. I chose progressive disclosure — basic access granted at sign-up, with KYC gates applied at the point of action that requires it. This matches regulatory requirements to user actions rather than blocking entry entirely.
Decision 2
Reusable Beneficiary Architecture Over Per-Transaction Entry
Operations teams don't send one-off payments — they manage recurring payouts to the same recipients. I built a beneficiary directory with saved, validated profiles. The beneficiary needed to be a first-class entity in the data model, not a form field. This reduced error rates and eliminated repetitive data entry for recurring payouts.
Decision 3
Status Taxonomy Designed Around Operator Actions
Webhook events produce technical state names that mean nothing to a finance operator. I mapped technical states to operator-meaningful states with explicit action prompts. 'FAILED_RETRY' became 'Payment rejected — review reason and re-initiate.' The operator needs to know what to DO, not what the system is doing internally.
Outcome
Reduced operational friction in payout initiation
KYC completion rate improved through progressive onboarding
Beneficiary reuse reduced per-transaction data entry errors
Transaction status system reduced support tickets related to payment confusion
Scalable architecture extended to support new payment corridors without redesign
What I'd Do Differently
I'd push earlier for real compliance documentation from the legal team. Halfway through the KYC design, requirements shifted for one jurisdiction — which required a rebuild of a flow I'd already finalized. That was a coordination failure, not a design failure — but I'd structure the discovery phase to force that clarity upfront next time.