FinCorp Vendor-Sales Verification Bot — I Built a WhatsApp Compliance Chatbot for a ₹5–50L Loan Network in a Week

5 hours ago

6 min read

Case Study · Solo Build · Fintech Compliance · 2026

Role: AI Product Consultant, solo build
Scope: Concept pitch → validated Phase 0 pilot · 3 verified test vendors
Stack: WhatsApp Business Cloud API, FastAPI, Notion API, Python, ngrok
Domain: Financial Services · Lending Compliance · Rural + Urban India
Status: Phase 0 pilot validated — not yet in production
Period: September 2026

*FinCorp is a fictional name to not reveal customer name.

Verdict: Technically proven, one Meta approval away from real deployment.

The concept works end to end. The bottleneck isn't the software — it's a WhatsApp message template sitting in Meta's review queue.

Section 1 — The Problem

FinCorp disburses loans of ₹5–50 lakh across rural and urban India through a vendor network— small shop owners and cooperatives that act as the physical point of contact when a salesperson visits to explain loan terms on behalf of FinCorp. The vendor is often in a location FinCorp's compliance team will never visit in person.

This creates a verification gap with three concrete failure modes:

Ghost visits - a salesperson reports a visit that never happened
Mis-selling - interest rates, charges, or tenure explained incompletely or misleadingly
Off-channel demands - payment requested outside official process.

None of these show up in FinCorp's systems unless someone asks the vendor directly — and manual phone-based verification doesn't scale across hundreds of vendors spread across states, doesn't produce a timestamped audit trail, and depends entirely on a human being available to make the call.

The instinct was to build a chatbot. The harder question was whether a non-coder could actually stand one up against a real, production messaging API — not a demo, a real webhook receiving real replies — in a timeframe short enough to be useful for a pitch.

Section 2 — What Was Built

A structured, WhatsApp-based verification flow: eight closed-ended questions (visit confirmation, visit date, disclosure of rate/charges, disclosure of full package terms, off-channel payment check, comments, satisfaction score), triggered per loan record, with automatic escalation flagging on any response that suggests a compliance risk.

Architecture: a Python seed script generating simulated loan/vendor/agent records (since no live sales-visit log existed to trigger from); a FastAPI webhook receiver tracking each vendor's progress through the 8-step flow by phone number; a Notion database as the system of record, storing every answer and computing escalation status (Clear / Escalated) the moment a flow completes; the WhatsApp Business Cloud API for send/receive; ngrok for local webhook exposure during the pilot.

Timeline: PRD and architecture drafted in an afternoon. Meta WhatsApp Business API setup, Notion integration, seed data, and the FastAPI webhook logic built and debugged over roughly a week of spare time. Three real phone numbers used as pilot "vendors," running the full 8-question flow successfully by the end of that week.

Section 3 — Key Decisions

Decision 1: A deterministic state machine, not an open-ended LLM conversation.

The flow is hard-coded — eight fixed questions, fixed branching, no free-form AI dialogue deciding what to ask next. This was deliberate: a compliance tool's output needs to be defensible in an audit, and a fixed question sequence is far easier to justify to a regulator than "the AI decided to ask this."

Trade-off: less natural as a conversation, more like a form delivered one message at a time. Acceptable for a compliance use case; would not be acceptable for a product where conversational quality is the point.

Decision 2: WhatsApp as the channel, not a web portal or IVR.

Given the vendor base spans low-connectivity rural regions alongside urban ones, WhatsApp was chosen over a web-based portal (assumes reliable data and login behaviour) and IVR (higher build complexity, slower per interaction). Most vendors already have WhatsApp installed and use it daily for business.

Trade-off: WhatsApp restricts business-initiated conversations to Meta-approved message templates unless the recipient has messaged first within 24 hours. This directly limits how FinCorp can trigger the flow — see Section 4.

Decision 3: Notion as the pilot's system of record, not a custom dashboard.

Rather than building a bespoke backend and admin UI to track responses, the pilot writes directly to a Notion database with select-field escalation logic built in. Zero to a working, filterable, shareable tracker in under an hour.

Trade-off: Notion's API is not designed for high-volume transactional writes and will need replacing before any real scale — but for a 3-to-10-vendor pilot, it was the fastest path to something a compliance stakeholder could actually look at.

Decision 4: Vendor-initiates-first, instead of waiting on template approval.

The original design called for FinCorp to auto-trigger the verification message N days after a logged sales visit — which requires an approved WhatsApp template, typically a multi-day Meta review cycle. For the pilot, the flow was inverted: the vendor sends any message first (opening a free-form session), and the bot recognises their number against a pending record and starts the flow.

Trade-off: doesn't match the intended automatic trigger design, and won't work at scale where FinCorp needs to initiate contact — but it meant the pilot could be fully tested this week instead of blocking on Meta's review queue.

Section 4 — What Broke

Failure 1: Environment assumptions cost more time than the actual logic.

pip wasn't pip3 on this machine. A .env file existed but was never actually loaded by the application — a bug introduced by not initialising dotenv before importing modules that read environment variables at import time. Neither issue was about the chatbot logic at all; both were basic environment hygiene that should have been checked before writing a single line of application code.

What I'd do differently: validate the full local dev environment (Python version, package manager, environment variable loading) with a trivial throwaway script before writing any real application code against it.

Failure 2: Notion silently split "database ID" from "data source ID."

A database query returned a 404 for two stacked reasons: the database hadn't been shared with the integration, and — separately — the ID being used was the newer "data source ID" rather than the "database ID" the API version in use actually expected. Two distinct bugs presenting as one generic error.

What I'd do differently: when an API returns a bare 404 with no further detail, log the full response body immediately rather than assuming the status code alone tells the whole story — the actual Notion error message named the exact missing permission the moment it was surfaced.

Failure 3: Meta's dashboard "Test" button validates the wrong thing.

Two full days were lost here. The webhook URL was verified. The messages field showed as subscribed. Meta's own "Send Test" button successfully hit the local server. A real WhatsApp message from a verified test number still produced nothing.

The actual cause: verifying a webhook URL and subscribing an app to a specific WhatsApp Business Account are two separate operations. The dashboard's test button only confirms the first. The second requires an explicit API call — POST /{WABA_ID}/subscribed_apps — that is not surfaced anywhere in the standard setup flow for this account type.

What I'd do differently: check the WABA's subscribed-apps list via the Graph API directly, on day one, rather than trusting the dashboard UI's built-in test as proof the pipeline works end to end.

Section 5 — Outcomes

Full 8-question verification flow completed successfully across 3 real phone numbers over live WhatsApp, with zero manual data entry — every response logged and escalation-flagged automatically in the Notion tracker.

Concept-to-validated-pilot in roughly one week of part-time solo work, spanning PRD, architecture, live third-party API integration, and debugging, without a dedicated engineering team.

Escalation logic (visit not confirmed, incomplete disclosure, off-channel payment request) correctly separates "Clear" from "Escalated" responses automatically, removing the need for a human to manually review every single response — only the flagged ones.

Not yet resolved: the WhatsApp message template needed for FinCorp to auto-initiate contact per the original trigger design (N days after a logged visit) has not been submitted for Meta's review — the pilot currently depends on the vendor messaging first.

Section 6 — What I'd Do Differently

I'd submit the WhatsApp message template for approval in parallel with the technical build, not after it — Meta's review cycle is the single longest lead-time item in this entire project, and it wasn't on the critical path where it should have been.

I'd also spend the first hour of any new third-party API integration checking every underlying subscription/permission state directly via that provider's API, rather than trusting a dashboard's built-in "test" feature — in both the Notion and Meta cases here, the UI's test signal was technically true but practically misleading.

⚠️ Verdict: Smart but blocked on one approval.

The technical concept is proven — a non-coder can stand up a compliance-grade WhatsApp verification flow, with a real audit trail and automatic escalation logic, in about a week using AI-assisted development. The constraint isn't the architecture. It's that WhatsApp's business-initiated messaging rules mean the real trigger design (auto-contact N days post-visit) cannot go live until a message template clears Meta's review queue — a dependency with a timeline outside this project's control.

This doesn't scale by building more. It scales by submitting the template early enough that approval finishes before the rest of the pilot does.

The End.