Know what to build and need the keys? Which APIs are self-serve, which need a sales call, and which are licensed: Getting Access: APIs, Sandboxes and Keys →
What this is
The nine modules cover how each part of a fintech works. This playbook covers sequence — what to do first, what runs in parallel, and what takes so long that starting it late determines your launch date regardless of how fast you build.
Three pages sit under it:
Licensing and Access
Permission paths, capital requirements, realistic timelines, and the data you cannot buy directly.
Stack Selection
The decisions in order, which are reversible, and what to defer deliberately.
Go-Live and First 90 Days
What must be true before launch, and what to watch once real money is moving.
The sequence
Six phases. The important property is that phase 1 runs in parallel with everything else, because permission is measured in quarters and code is measured in weeks.
PHASE 0 - DECIDE (weeks 1-4, no engineering)
What exactly are you selling, to whom?
Which regulator owns that activity?
Do you need a licence, or a partner who has one?
What is the unit economics at 1,000 customers? At 100,000?
-> OUTPUT: a one-page regulatory position and a unit economics model
-> Most failed fintechs skipped this and built first.
PHASE 1 - PERMISSION (months 1-9, runs in PARALLEL with phase 2)
Start licence application, OR
Start partner conversations (NBFC / sponsor bank / PA)
Start data access conversations (bureau, AA, GST)
-> These take QUARTERS. Starting them late is what kills timelines.
PHASE 2 - FOUNDATION (months 1-4)
Ledger decision (Module 08)
Identity and onboarding (Module 01)
Event backbone + shadow ledger
Model inventory, from the first model (Module 09)
-> Build the audit trail NOW. Retrofitting costs several times more.
PHASE 3 - PRODUCT (months 3-8)
Your actual differentiated thing
Risk stack for your product: credit / fraud / AML as applicable
Customer operations with escalation designed in
-> This is the only phase where you are building your business.
Everything else is table stakes.
PHASE 4 - PROVE (months 6-10)
Shadow mode on every model
Reconciliation running clean for a full cycle
Kill switches tested
Conduct and complaints process rehearsed
-> GO-LIVE GATE. See the go-live checklist.
PHASE 5 - LEARN (first 90 days live)
Small volume, high scrutiny
Instrument everything - the proprietary data starts accumulating here
Review thresholds against real outcomes, not assumptionsThe single most common timeline failure: building for six months, then starting licence or partner conversations, then waiting another six. The build was never the constraint. Start the slow things on day one, even when they feel premature.
The order of the modules
If you are reading the modules rather than the playbook, this is the order that matches the build:
| When | Module | Why then |
|---|---|---|
| Before anything | Regulatory spine and why every fintech AI looks the same | They determine what you can build and what is worth building |
| Phase 2 | Infrastructure | The ledger decision constrains everything above it |
| Phase 2 | Identity and Onboarding | Nothing works until you can onboard someone |
| Phase 2 | Governance | The inventory starts with your first model, not your fiftieth |
| Phase 3 | Your product module — Credit, Payments or Wealth | This is the business |
| Phase 3 | Fraud and AML | Required before real money moves |
| Phase 3–4 | Customer Operations | Complaints and escalation must exist at launch, not after |
What to build yourself, and what not to
A rough allocation of effort that holds for most new fintechs:
| Layer | Effort | Rationale |
|---|---|---|
| Ledger and core | Buy or rent | Solved, expensive to get wrong, not differentiating |
| KYC and identity | Buy | Aadhaar access is indirect anyway — Module 01 |
| Sanctions screening | Buy the data, tune the thresholds yourself | The list enrichment is what matters — Module 04 |
| Fraud detection | Start with rules you write | Velocity features beat any vendor in week one — Module 03 |
| Credit model | Build, on bought data | Your repayment history becomes the moat — Module 02 |
| Reconciliation | Build the shadow ledger, buy the matching if volume demands | Module 05 |
| Support | Buy the platform, design the escalation yourself | Module 06 |
| Your product logic | Build, obviously | This is the company |
The pattern to avoid: building the commodity layer well and the differentiated layer late. Eighteen months of excellent OCR pipeline while the thing that would have distinguished you went unbuilt is the most common engineering failure in the sector, and it feels productive the whole way through.
Three things to instrument from day one
All three are cheap now and impossible to reconstruct later.
1. Outcomes, not just decisions. Every approval, decline, override, complaint and repayment. This is the proprietary data that becomes your advantage — and it only exists if you captured it from the first transaction.
2. The reject slice. Approve a small random percentage of applicants you would otherwise decline. It feels like deliberate losses and it is the only way to learn what sits just outside your cut-off. Budget it as data acquisition, not as write-offs.
3. Model and policy versions on every decision. Not the score — the version of the thing that produced it. "Which model made this decision" is the first question in any examination and the hardest to answer retrospectively.
The failure modes, in order of frequency
- Started permission late. Licence or partner conversations begun after the build. Adds two to three quarters to launch and cannot be compressed with money.
- Built the commodity layer. Time spent rebuilding solved problems while the differentiator waited.
- No audit trail until asked for one. Retrofitting decision logging across a live system is several times the cost of building it in.
- Discovered the business model was not permitted. Usually a conflict-of-interest rule — advice plus execution, or commission plus recommendation.
- Underestimated human review cost. Review queues and exception handling are usually the largest operating line and rarely appear in the model.
- Launched without a complaints process. It becomes urgent on roughly day three.
A prompt for sequencing your own build
You are a fintech operator who has taken products from idea to
launch in India, including the regulatory path.
My situation:
- Product idea: [describe in detail]
- Team: [size, and what skills]
- Funding and runway: [amount, months]
- Target launch: [date]
- Licence position: [none / applying / partnering / hold one]
Give me:
1. A phase-by-phase plan with realistic durations, showing clearly
what runs in parallel.
2. The three things I must START in week one because they take
quarters, not weeks.
3. What I should buy versus build, with the reasoning for each.
4. The point at which my stated launch date becomes impossible, and
what would have to change.
5. My likely unit economics at 1,000 and 100,000 customers, stating
your assumptions - including human review cost.
6. The regulatory question I have probably not asked yet.
7. What to instrument from day one that I will otherwise wish I had.
Be blunt about whether the timeline is realistic. If it is not,
say so plainly and say what would make it so.Sources
Every figure, rule and date on this page, and where to check it. Entries are typed so you can see which are primary-sourced and which are industry reporting.
- officialRBI licensing and authorisation pages — the authorisation categories and net-worth thresholds referenced. www.rbi.org.in
- officialSEBI intermediary registration — the adviser and analyst routes. www.sebi.gov.in
- industrySponsor bank and BaaS arrangements — the partnership structures described. Commercial arrangements vary; nothing here is a template.
Checked September 2026. Regulation in this area is actively developing; the date is part of the claim.
Ask an AI about this page
Opens your assistant with this page as the source, and a question rather than a summary. It will ask what you are building before it answers.
Nothing is sent from here. The link carries only this page’s title and address.