2026

REasy FinanceKYC redesign for a cross-border payments app

REasy helps African SMEs pay suppliers abroad in local currency and ship goods, all in one app. I was the sole product designer, working with the founders, Compliance and two engineers for six months.

I redesigned identity verification (KYC) so users reach the product first. Verification completion rose from 21% to 69%, and payment conversion held at 71%.

Team

Sole product designer (me)

2 engineers

Founders

Compliance

Engineering

Customer support

2026

The problem

79% of new users never reached the product

Regulation requires a full identity check (KYC) before any payment. REasy asked for it at signup, before users saw any value, and only 21% completed it.

Business impact

Paid acquisition was lost before the first payment

Funding a wallet, paying a supplier and every other revenue action sat behind the verification step.

User context

Users were asked at the worst moment

Many signed up in physical markets: away from home, without their ID, on unreliable connections, and unsure REasy was legitimate.

Solution

Progressive verification: ask for the minimum first

I split verification into three tiers. Tier 1 asks only for a liveness check, an ID, a name and a line of business, and unlocks payments within limits. Tiers 2 and 3 trigger with usage, up to the full regulatory check.

What each tier requires and unlocks.

Solution

Every screen shows the current tier and the next step

I made progress visible on every screen: what users have completed, what they can do now, and what's next.

Explore, check progress, get warned, verify, continue.

Design decision

Warn before a limit, never block a payment in progress

I put the warning on the home screen, one transfer before a limit. A payment that crosses a threshold still completes, and the new requirement applies to the next one.

Threshold warning on the home screen, then the requirement at the limit.

Design decision

Rejection recovery built into the main flow

Worn CEMAC ID cards often fail photo checks. I wrote a specific message and one recovery action for each of the nine rejection reasons, and saved progress so users resume where they stopped.

Rejected, in review, resuming.

Research

Context

Testing the hypothesis with a low-risk experiment

The required fields were set by regulation, so the variable I could change was sequence.

I shipped an experiment where users could explore the product before verifying, with regulated actions locked. Completion rose from 21% to 29%: sequence mattered, but seven in ten still dropped off.

Research

10 user interviews, funnel data and support tickets

I interviewed users who completed verification and users who abandoned it, then compared what they said with PostHog funnels and support conversations.

Goals:

1. Find out whether effort was the main cause of drop-off.

2. Understand what users needed before sharing ID documents.

What we heard, and what the design did about it

Findings, and the design response to each.

Participants

5 users who completed verification and 5 who abandoned it. In person at their workplaces, 7 interviews in French and 3 in English.

Research

Key finding: drop-off was about trust, not only effort

Users questioned why an unknown app wanted their documents, and many didn't carry them at work. Seeing the product work first gave them a reason to verify later.