NBFC Compliance Intelligence

The problem

Indian NBFCs operate under dense, frequently-amended RBI directions covering digital lending, recovery practices, disclosure, and grievance redressal. Compliance teams audit loan documents and call transcripts by hand against regulation text that keeps changing — slow, error-prone, and with no systematic way to prove which version of a rule applied to which event date. This system automates that retrospective audit end to end, while keeping a paper trail a human — or a regulator — can actually follow.

Architecture — four stages, each independently testable

Extract → an LLM pulls ~80 typed fields from raw document text against a versioned schema, every value grounded in a quoted, PII-redacted span of the source. Retrieve → resolves the regulatory corpus as of the event date (never "today"), via hybrid vector + lexical search fused with Reciprocal Rank Fusion. Decide → 28 hand-written deterministic rules run first; the model is only called when no rule resolves the fact, and every decision is logged with which one made it. Validate → the hard guarantee: no verdict ships without a citation that resolves to a real clause whose effective window contains the event date, enforced by a dedicated validator in code — a failure downgrades to "no clause found" rather than passing silently through.

A real production bug, found and fixed

Not a hypothetical — this happened. A local, from-scratch reproduction of the full stack (Postgres, Redis, Celery — no Docker daemon available, so everything was provisioned from raw packages) surfaced that the assessment pipeline was making its per-fact LLM calls sequentially. Eight facts took 33.8 seconds; a real document with 15–20 facts would blow past any reasonable timeout. The fix: fan the independent per-fact assessments out concurrently, bounded by a semaphore — roughly a 4x wall-clock improvement, with a regression test written specifically so it can't silently regress back to sequential.

Security and data posture

• Zero raw-document persistence by architectural constraint — extraction runs synchronously inside the API request, so document text never crosses a message-broker boundary in the first place.
• Row-level security in Postgres for tenant isolation, plus SHA-256 tenant-token auth.
• Content-free logging — ids, durations, hashes, and verdicts, never document content — with full LLM cost/latency/token accounting per call.
• Versioned, hash-pinned regulatory corpus — the ingest pipeline records source URL, retrieval timestamp, and content hash for every clause; nobody hand-edits regulation text.

Deployment

Live on Fly.io: four processes (Redis, Celery worker, backend API, reverse-proxy gateway) inside a single Firecracker microVM for near-zero cost, with the backend bound to loopback-only and only the gateway internet-facing — genuine defense-in-depth, not cosmetic. Neon serverless Postgres for the database tier, with a custom domain and TLS via Fly-managed Let's Encrypt certificates. The demo frontend is hand-built with no framework: client-side PDF parsing (no backend load) and a live 5-stage pipeline visualization driven entirely by real telemetry — no fabricated data.

Ownership

I designed and shipped this alone, end to end: the regulatory data model, the four-stage pipeline, the security posture, the deployment topology, and the incident above — root-caused by reproducing the full stack locally rather than guessing at the fix. Same shape of ownership I'd bring to a production LLM system on a team: not just the model-calling code, but the trade-offs, the failure modes, and being accountable for both.