An NBFC lending stack, from application to collections

The problem

Lending is not a product, it’s a chain, and every link is a different vendor. A borrower applies, is verified against government identity systems, assessed against a credit bureau, approved inside the lender’s own origination system, mandated for auto-debit through a payment gateway, disbursed over banking rails, then chased for repayment across months. Break any link and money either doesn’t move, or moves when it shouldn’t.

Walkfin’s additional difficulty was that a loan lives in two systems at once (Walkfin’s and the NBFC’s) and the two must never disagree about its state.

What we built

We delivered the back-office web admin and the borrower’s React Native app on the Play Store.

Loan products are configured, not coded. Each product defines its own application steps and questions, so education loans ask about institutes and courses while invoice financing asks about business vintage and tax registration, with no branching in the application engine itself.

Identity verification runs two ways: government IDs checked against a verification provider with the full OTP session flow, and uploaded PAN card images read through OCR with heuristic line filtering to strip the boilerplate every card carries.

The integration with the NBFC’s origination system covers lead creation, loan creation, KYC push, credit bureau submission, credit limit setting, drawdown requests, mandate registration and repayment sync. The latest request and response for every integration step is persisted, and every NBFC callback is kept, so any disagreement between the two systems can be traced rather than guessed at.

The workflow

1. Borrower verifies mobile and email; for invoice discounting, the borrower is the wholesale distributor
2. Product selected; the application form is served from that product’s step configuration
3. Identity documents verified and OCR’d; supporting documents uploaded
4. Back-office review: documents, then the application itself
5. Approved application syncs to the NBFC; bureau data submitted; credit limit set
6. Borrower registers a bank account; e-mandate authorised for recurring debit
7. Drawdown requested with amount, EMI count, schedule and fee breakdown
8. NBFC disburses and calls back with the transfer reference; loan marked disbursed
9. Scheduled jobs send reminders before due date, penalty notices after, with interest and tax broken out
10. Collections captured through gateway webhooks, written as transactions, synced back

What was hard

Three state machines had to agree (the application’s, the NBFC’s, and the drawdown’s), reconciled through webhooks and a per-step request log, with every inbound NBFC webhook kept, rather than a single authoritative source, which doesn’t exist in a two-party lending arrangement. Payment webhooks are signature-checked and ignored once settled. Every application state transition timestamps itself and resets everything downstream of it.