There is a twelve-session track for children on how money and AI actually work — ledgers, identity, fairness, and spotting a scam. Ages 9–13, parent present, no real money: Money Explorer →
Nineteen product guides, and a front door organised by what you are trying to build rather than by what it is called: Fintech Product Guides →
Four bodies regulate Indian fintech and they do not divide the ground neatly: Who Regulates What →
Regulation is the part of a build that moves after you have finished: Regulatory Changelog → — what changed, when, and what commences next.
What this is
A reference hub for building financial technology with AI. Not a course and not a vendor list — a set of nine modules organised around the problems a fintech actually has to solve, each covering how the problem works, which AI approaches apply, what tools exist right now, and how to implement them.
It is written so that the Beginner lane is readable by someone with no financial background, the Intermediate lane gets an engineer building, and the Advanced lane covers what a risk officer or regulator will ask about.
Use the depth selector on the left. It follows you as you scroll. Every code block and prompt has a copy button — take them straight into whichever AI assistant or editor you use.
The nine build sheets
Each module has a build sheet: every tool, how to use each one, the first working call, the gotcha nobody documents, real cost per unit, and three recommended builds at three budgets.
The 19 product guides
A module explains how a capability works and a build sheet lists what to buy for it. A product guide walks one product from end to end: every step, your options at each one, what goes in, what comes out, how to connect it to the next step, and what breaks.
The nine modules
Build Playbook
How to sequence all of this — phases, what runs in parallel, licensing and access, stack selection, and the go-live gate.
Identity & Onboarding
KYC, video KYC, liveness, document OCR and the extraction pipeline that actually works on Indian documents.
Credit & Underwriting
Scoring models, alternative data, thin-file applicants, and adverse action you can defend to a regulator.
Fraud & Risk
Transaction monitoring, device and behavioural signals, and the false-positive problem that decides whether it ships.
AML & Compliance
Sanctions screening, name matching, SAR narrative drafting and regulatory reporting.
Payments & Reconciliation
Matching engines, exception handling, disputes and chargebacks.
Customer Operations
Support agents, collections, complaints handling and the escalation design that keeps you compliant.
Wealth & Advisory
Robo-advice, suitability, and the line between information and regulated advice.
Infrastructure
Core banking, data architecture, the build-versus-buy reality and what it actually costs.
Governance
Model risk management, explainability, bias testing and the audit trail a regulator will ask for.
Each module stands alone. You do not need to read them in order, though Identity and Governance are the two most people should read first — one because every fintech starts there, the other because ignoring it is what kills products at the compliance review.
Who this is for
Someone starting a fintech. You have an idea and need to know what is genuinely buildable, what it costs, what is regulated, and where to begin.
Engineers already inside one. You need the implementation detail for one specific problem — the OCR pipeline, the matching engine, the screening logic.
Innovation and risk teams in banks. You need to evaluate what a vendor is claiming, and what questions to ask.
It assumes no prior knowledge in the Beginner lane and no hand-holding in the Advanced one.
How it is organised
Every module follows the same three-lane structure:
| Lane | What it covers | Written for |
|---|---|---|
| Beginner | What the problem is, why it is hard, what AI can and cannot do about it | Anyone, including a ten-year-old for the opening sections |
| Intermediate | The actual pipeline, the tool options with honest trade-offs, working code | Someone building it |
| Advanced | Failure modes, thresholds, regulatory exposure, what breaks at scale | Risk, compliance, and engineers shipping to production |
Each module also carries a tool registry marked direct (you sign up and call an API), indirect (reachable through a BaaS, aggregator or partner) or open source (you host it yourself). Registries carry a verification date because they decay faster than anything else on the page.
Start here if you are building
The order that works for most new fintechs:
- Read the regulatory spine for your market first. It determines what you are allowed to build, which changes the product. Doing this after the build is the single most expensive mistake in the sector.
- Module 1 — Identity. Every regulated financial product starts with knowing who the customer is. Nothing else matters until onboarding works.
- Module 8 — Infrastructure. Decide build versus buy before writing code, not after.
- Your core product module — credit, payments, wealth, whichever you are actually selling.
- Module 9 — Governance. Build the audit trail as you go. Retrofitting it is several times more work.
The regulatory spine
Regulation is not a chapter in fintech — it is the shape of the product. Two reference pages carry it:
Regulatory spine — India
RBI, UPI, Account Aggregator, DPDP, digital lending guidelines and what they permit an AI system to do.
Regulatory spine — global
EU AI Act, GDPR, FCA, US federal and state patchwork, and how they differ on automated decisions.
Nothing here is legal advice. It is a map of what exists so you can ask a qualified adviser the right questions. Regulation changes; always verify the current position for your licence and jurisdiction.
The thing nobody tells you
Almost every fintech AI product is built on the same handful of models, the same few data vendors and the same public regulatory texts. The AI is not the differentiator and has not been for some time.
This is important enough to have its own page, because getting it wrong shapes an entire company strategy around the wrong thing.
On the tool registries
Every registry entry is marked with a verification date and a category:
| Marker | Meaning |
|---|---|
| direct | You sign up, get credentials, call an API. You are the customer. |
| indirect | Reachable only through a partner — a BaaS provider, a licensed entity, an aggregator, or a reseller. Often the only legal route for an unlicensed startup. |
| open source | You host and operate it. No vendor, no per-call cost, all the operational burden. |
The indirect category matters more than people expect. A large share of what a new fintech needs — bureau data, account aggregation, certain payment rails, some KYC databases — is not available directly to an unlicensed company at any price. Knowing the indirect route is frequently the difference between a product being buildable and not.
What this hub will not do
It will not give you legal or compliance sign-off. Code and architecture here are illustrative and correct in pattern. Anything touching KYC, AML, credit decisions or customer money needs review by people qualified and accountable for it in your jurisdiction.
It will not stay current by itself. Architecture and failure modes hold for years. Vendor names, pricing and model capabilities do not. Registries carry dates so you can see what to re-verify.
It will not pretend the hard parts are easy. Where a problem is genuinely unsolved — false positives in transaction monitoring, explainability in deep models, name matching across scripts — it says so rather than selling a tool as the answer.
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.