B2B Fintech · Payments
Data Cascade
Nearly half of all merchant registrations needed manual compliance review. Everyone saw a form. I saw a data cascade, redesigned the architecture around sequential dependencies, and the pattern is now the default across every onboarding channel.
- 53%
- First-pass approval, before
- 75%
- Auto-approval target
- 240
- Address errors/month eliminated
- Role
- Senior Product Designer
- Focus
- Registration architecture
- Duration
- 2025–2026
Owned end-to-end registration design across assisted and self-service onboarding. Designed across three team boundaries (sales platform, compliance verification, self-service onboarding) as a peer to Product and Engineering leadership.
The form wasn't a form
Registration collected business details, trading locations, identity documents and banking information, and users could fill sections in any order. The assumption was that flexibility would help. It didn't: business details from the national registry pre-populate everything downstream, so open order created orphaned, conflicting data. One convenience toggle generated 240 incorrect address cases in 30 days, each needing manual compliance follow-up. First-pass approval sat at 53% against a 75% auto-approval target, and every field decision connected to that number.
Three stakeholders, one word, three meanings
A conversation about 'dynamic rendering' had stalled: Product meant boolean conditions, Engineering meant schema-driven rendering, compliance meant backend-driven document requirements. I asked for concrete examples (pharmacies, shooting ranges, medical services) and the abstraction split into clean scope: fixed conditionals in MVP, known restrictions next, truly dynamic schema deferred. A definitional gap was blocking implementation; naming it unblocked delivery the same day.
Key decisions
01
Chose data consistency over open-form flexibility
I proposed locking sections sequentially and argued from two kinds of evidence: the dependency chain itself, and interviews showing users defaulted to left-to-right anyway. The PM moved from resistance to 'start constrained, loosen on feedback'. The flexibility wasn't serving users; it was creating compliance work.
02
Brokered the desktop/mobile compromise
The PM wanted a condensed desktop form; Engineering said that meant two schemas. I proposed mobile-first responsive for the pilot plus a desktop review version, and volunteered to absorb the extra work. The scope tension resolved in one meeting.
03
Read the form as a data cascade
Everyone saw a form; I saw sequential dependencies. Business details from the national registry pre-populate everything downstream, so upstream verified data had to populate and constrain what follows. That reframe is what the whole redesign hangs off.
04
Traced 240 errors to one convenience toggle
A single toggle meant to save users time generated 240 incorrect address cases in 30 days, each needing manual compliance follow-up. Evidence like that turned the flexibility argument from opinion into cost.
05
Made three teams define 'dynamic rendering'
Product meant boolean conditions, Engineering meant schema-driven rendering, compliance meant document requirements. I asked for concrete examples and the abstraction split into clean scope: fixed conditionals in MVP, known restrictions next, truly dynamic deferred. Unblocked the same day.
06
Stress-tested my own design before production
I went looking for the failure modes in my own work and surfaced three validation gaps pre-production: the three-name conflict, the manual-store gap, and the mismatch-versus-edit distinction.
Outcome
The sequential data-cascade pattern is now the team's default for multi-section forms, the select-identity-first pattern became the standard for signatory identification, and the scope distinctions clarified sprints I wasn't in. The registration flow I designed is the foundation the pilot shipped on.
53%
First-pass approval, before
75%
Auto-approval target
240
Address errors/month eliminated