Banks told us onboarding took 3 days because of backend processing. The real problem was a 60% drop-off in the first 10 minutes — and no mechanism to tell users why they failed. Switching the north star metric changed the entire roadmap.
Signzy builds digital onboarding and identity verification infrastructure for Indian banks. Clients included Yes Bank and IndusInd Bank — processing hundreds of thousands of new account applications monthly. KYC (Know Your Customer) is a mandatory regulatory step under RBI guidelines before any account can be opened.
Joined as Product Owner with a mandate to improve the KYC onboarding product. The sales team's summary: "Our clients tell us customers are dropping off at document verification. We're not sure why." No hypothesis. No data. That was the brief.
"Our clients tell us their customers are dropping off at document verification. We're not sure why."
— Sales lead, first weekThe surface diagnosis was: KYC takes 3 days and has high rejection rates. Speed it up. The implied solution was backend optimization — faster processing pipelines, better infrastructure.
Before writing a single spec, I pulled 3 months of transaction logs. What I found completely changed the problem statement.
Not during backend processing (which happened hours later). During the document upload phase — the very beginning of the session. If users were failing in minute 1–10, this was a UX problem, not a processing speed problem.
Finding: UX failure, not backend failurePoor lighting, cropped edges, blurred images. The validation happened server-side, hours later. By then, users had given up. There was no real-time feedback to help them fix it immediately.
Finding: No feedback loop at the point of failureClient interviews with Yes Bank and IndusInd ops teams revealed their biggest pain wasn't the rejection rate — it was the support ticket volume. Failed KYC → customer complaint → ops ticket → resolution. At 500K+ monthly applications, this was a significant cost centre.
Finding: The real client pain was ops burden, not speedAverage processing time masked the bimodal distribution. Users who passed flew through; users who failed dragged the average down. The right metric was first-attempt success rate: if users passed on the first try, everything downstream got faster automatically.
Switching metrics changed the entire roadmap. We were no longer trying to speed up the backend. We were trying to prevent failures from happening in the first place.
The key insight: in B2B, you have two users — your direct client (the bank) and their customer (the account applicant). Understanding both was not optional. Solving for ops teams without solving for the end user produces better dashboards but not better KYC.
Pulled and mapped the funnel stage-by-stage. Where were users dropping? At what rate? At what time of day? The headline finding: 60%+ of failures happened in the first 10 minutes. This pointed to the document upload phase — not the backend. The backend was fine.
Duration: 2 weeks · Method: Funnel analysis, session log reviewSpent 1 week talking to bank operations leads. Their biggest pain wasn't the rejection rate — it was the support ticket volume. Each failed KYC generated a support escalation. At scale, this was a significant cost. Their ask: "Help our customers succeed on the first try, or at least tell them what to fix."
Duration: 1 week · Method: Structured interviews, pain point mappingBackend processing bottleneck. A speed problem. Something we could fix with infrastructure or model optimization. The obvious hypothesis given the complaint.
The 10-minute drop-off data. Users weren't abandoning after waiting for backend results — they were giving up before the backend ever saw their document. Entirely different problem.
I ran a value vs. effort matrix across 14 potential improvements, scored specifically against impact on first-attempt success rate (the new north star, not the old "time to approve"):
| Feature | Impact on Success Rate | Effort | Compliance Risk | Priority |
|---|---|---|---|---|
| Real-time document quality feedback | Very High | Medium | Low | P0 |
| Guided capture UI (frame overlay) | High | Low | Low | P0 |
| Rejection taxonomy + specific error reasons | High | Medium | Low | P1 |
| Retrain liveness model on India-specific data | Very High | High | High (RBI validation required) | P1 |
| Automated resubmission reminder flow | Medium | Low | Low | P2 |
The model retrain scored high on impact — but only after accounting for compliance risk and effort did it drop to P1. The critical move was adding compliance risk as an explicit column, not treating it as a separate filter. It changed what P0 looked like entirely.
The data science team pushed hard to retrain the liveness model first. It was the technically impressive problem and the one with the most engineering excitement. Their argument: model accuracy is the root cause.
My counter-argument: Retraining takes 8 weeks minimum and carries deployment risk — all model updates need RBI-aligned validation before they touch production. The guided capture UI ships in 3 weeks with near-zero compliance risk. And our data showed 60% of failures were at document upload (UX), not liveness (model). We would spend 8 weeks fixing 40% of the problem instead of 3 weeks fixing 60% of it.
What I risked: If I was wrong about the data — if liveness failures were actually the bigger problem — I would have delayed the right solution by 3 weeks and lost credibility with the data science team.
First-attempt success rate improved 28% — without touching the model. The document upload phase accounted for exactly what the data predicted. The model retrain followed in Phase 2 and added the remaining accuracy gains.
Frame overlay that positioned the document correctly. Lighting indicator showing ambient light quality. Auto-capture trigger when quality threshold was met. Users no longer guessed whether their photo was good — the UI told them in real time before submission.
Quality check moved from server-side (hours later) to client-side (instant). Users saw specific feedback — "Image too blurry," "Edge cropped," "Low light detected" — before submitting. Eliminated the 42% low-quality upload rate.
Built a categorization system for rejection reasons. Bank ops teams could now see why customers were failing, not just that they were. Also provided a client-facing dashboard — banks could see their own KYC funnel in real time.
Retrained the model on lighting conditions common in tier-2 Indian cities (high ambient light, low-contrast backgrounds). Delivered remaining accuracy gains after Phase 1 UX improvements. RBI validation completed before deployment.
A backend processing speed optimization. The original request. We didn't touch the processing pipeline because the data showed it wasn't the problem. Not building this was as important a product decision as anything we shipped.
| Decision | What I Chose | Why | Alternative Rejected |
|---|---|---|---|
| Phase order | UX improvements first, model retrain second | Faster time-to-value, lower risk, addresses the larger failure mode (60% vs. 40%) | Model retrain first — higher effort, lower coverage, compliance risk delayed timeline |
| Error feedback | Specific error codes with user-facing explanations | Reduces support tickets; enables user self-service; removes ops burden from banks | Generic "rejected" message — faster to build but zero learning for the user |
| Compliance approach | All changes reviewed before sprint commit | RBI violations = contract loss. Better to slow down 1 week than ship and scramble | Build first, get sign-off later — too risky for a regulated product |
| North star metric | First-attempt success rate | Exposes the bimodal distribution that "average processing time" hides; targets the real failure mode | Time to approve — optimizes the wrong part of the funnel |
The ops-side metric also moved significantly: support ticket volume from KYC failures dropped materially across both bank clients. Yes Bank and IndusInd cited this as the primary driver of their satisfaction improvement — not the speed gain, not the accuracy improvement. The reduction in their support burden.
Average processing time masks the bimodal distribution. Users who pass fly through; users who fail drag the average down catastrophically. Switching to first-attempt success rate forces you to focus on preventing failures, not hiding them in an average.
The banks were my direct clients. But the people actually struggling were their end customers. I had to understand both constituencies to solve the problem correctly. Talking only to the bank would have produced a better dashboard, not a better product.
I was initially frustrated by how much slower everything moved because of RBI compliance requirements. By the end, I realized that Signzy's ability to ship compliant products reliably was the product. Banks can't build this capability themselves — that's why they pay for it.
When it's a separate filter, you make compliance a binary gate. When it's a column, it becomes a cost you can trade off against impact. That distinction completely changed which features were P0 in our matrix.