Published with KFintech’s permission. Every name, ID, scan and signature shown is a dummy, and the product’s branding is changed. Happy to walk through the real work on a call.
Problem
66 fields, all by hand
A brand-new digital platform, and its main input was a scanned paper form. Nothing gets approved until a person has checked every field on it.
In India, nobody invests before a KYC check. A KYC Registration Agency stores each record once, so any broker or fund can reuse it.
A maker at the broker or fund scans an 8-page form and types 66 fields per person. A checker at the agency reads every field again. Ops staff, the business analyst and the product owner told us mistakes surfaced late, and applications went on hold.
Three rules shaped every screen: a person verifies each field, fields follow the official form, and launch waited on SEBI, the market regulator.
We wanted makers to type less, and mistakes caught at the field, not after submission.
Investor
Fills in a paper KYC form
Broker or fund, the maker
Scans the form and enters the fields
KYC agency, the checker
Verifies every field, then approves or holds
Branch: another KYC agency. A change to a record it holds travels there as a formal request
One stored record
Checked once
Any other broker or fund
Fetches the record by PAN, India’s tax ID
One record, checked once, reused by every broker and fund. Drawn for this case study.
Maker
Staff at a broker or fund
- Job
- Turn a paper form and documents into a KYC application.
- Pain
- Typing 66 fields from a scan.
Authorizer
Senior staff at the same firm
- Job
- Approve a modification before it leaves the firm.
Checker
Operations staff at the agency
- Job
- Verify every field against the scan, then approve or hold.
- Pain
- Rereading every field to find the few the OCR missed.
Three roles touch one modification. Reconstructed from the requirements document’s role list.
Context
A new agency, a fixed date
This was my first project at KFintech, and a new domain for the company. Five agencies already did this work, so we looked for new technology that could take the typing off people’s hands.
Three designers shared the screens. I drew the first drafts of registration, KYC entry and KYC review; the other two built on that base.
Two things were hard. I had to learn KYC in my first weeks, from the requirements document and the ops team. And I had to show a machine’s best guess to people who must not get a single field wrong.
Deep dive: how KYC works in India, for readers outside it
An intermediary is any firm registered with SEBI, India’s market regulator, that sells investments: brokers, mutual funds, advisers. The intermediary collects the form and documents, and its staff enter the data. The agency checks it and stores one record.
Any other intermediary can then fetch that record with the investor’s PAN, India’s tax ID. If details change, the intermediary files a modification. If the record sits with a different agency, the request travels there.
Each record carries a status: registered, validated, on hold or rejected. On hold means new investments through that record can’t go ahead until the investor fixes it.
- 20 Jan 2025I join KFintech. My first project, after onboarding. I start with the requirements document and the team.
- Feb–Apr 2025Two drafts, then hi-fi. My accordion drafts become a viewer and a stepper; two designers build on them.
- 30 Apr 2025Launch. SEBI grants registration and the agency goes live with our screens.
- May–Jul 2025After launch. Fixes and new screens until I move fully to other products.
100 days from joining to launch, then three more months of fixes and new flows.
Broker or fund, maker
Create application
PAN, name, date of birth, scan
PAN already on record → Modify
Under 18 → guardian fields
Company PAN → 8-step path
Work tray
The application waits in the queue
7 or 8 steps
OCR pre-fills each field and flags unclear ones; the maker confirms
Submit
Sent to the agency
KYC agency, checker
OCR flags
Unreadable and blank fields
Checker review
A ring per section, then every field verified
Unlocks once every field is verified
A reason per section, back to the maker
The whole loop, with the three places it branches. Reconstructed for this case study.
Change 01
The paper stays in view
Typing from paper means reading and writing at once. So the scan stays on the left in a viewer, beside the fields and a stepper.
The requirements document used OCR only at the end, to compare. In a team brainstorm, we added it at the start: it pre-fills each field, and the maker confirms. A careless confirm still gets caught, because the checker opens every section and confirms it.
My part was what the maker sees once the OCR has read the form. Select a field and its box lights up on the scan. Unsure readings carry a flag.
Change 02
Start where the OCR struggled
The checker rereads all 66 fields, so I gave them a head start. Each section gets a ring: the share of fields the OCR read cleanly.
The OCR flags the regions it can’t capture and the fields left blank. Anything under 100% turns the section red. The ring approves nothing; it shows where to look first.
Change 03
Approve waits for every field
Maker-checker means one person enters and another verifies. The requirements document made Approve wait for every field. My job was to make that lock feel fair.
So the checker always sees what is left: the ring and a Verified mark per field. Hold asks for a reason by section, so the maker knows what to fix.
Deep dive: how a modification is reviewed
A change to an existing record first passes an authorizer at the broker or fund. At the agency, the checker compares the old and new signature and marks it Matched or Unmatched. Then each supporting document gets a tick or a cross.
Last, old and modified data sit side by side, with the changed sections flagged, so the checker reads only what moved. If another agency holds the record, the change travels there as an interoperability request, a formal hand-off between agencies, and its status is tracked until it returns.
What failed
My long form lost the argument
I argued for one long form, with markers where there was a mistake. That way nobody has to click sections open again and again.
The team disagreed: long forms confuse, and short sections let a maker verify one part at a time, or skip one whose details haven’t arrived.
Paperwork often arrives in pieces. That argument won, and the stepper shipped.
Craft
Rules the form already knows
Every rule the system can apply is a field nobody types.
A verified PAN, India’s tax ID, fills the name from the tax database and locks it.
The work tray, the queue of applications, colours each row red, amber or green by turnaround time.
The state colours as shipped. Most miss AA contrast, so every state also carries a word.
Outcome
Live on launch day
The agency got SEBI registration and launched on 30 April 2025. Our screens shipped close to the designs. The flag and highlight look different in the build. I stayed on until July, adding new flows.
It sits behind a login, so I have no usage numbers. What I’d measure:
Fields the OCR reads right the first time
Applications approved without a hold
Time from upload to approval
Holds by reason
Sections that open green, so the ring isn’t noise
“Having Amandeep on the project sped up production. His coordination was a big positive for the project, and his ideas helped us steer the design in the right direction.”
Names left out for privacy. Happy to share references.
Retrospective
Draw the bad scans too
Two things I’d change. Three designers shared one base, so I’d set up shared components on day one. And I’d draw the bad scans in the final file. The highlight and flag shipped from my early drafts; the final file never showed them.