--- title: "Sarthi — RAG Relationship-Manager Copilot for Banking" description: "Sarthi, by Shreyansh Kumar Singh: an AI relationship-manager copilot for banking — RAG, grounded chat, and a published P0–P3 security self-audit." url: https://www.shreyanshkumarsingh.com/projects/sarthi-rag-banking-copilot author: Shreyansh Kumar Singh updated: 2026-10-08 --- # Sarthi: an AI relationship-manager copilot for banking By Shreyansh Kumar Singh. Independent hackathon project. Source available on request. **How should a RAG copilot for banking be structured — and audited?** Sarthi is an AI copilot for bank relationship managers: twelve modules — Customer 360, risk, loans, lead scoring, a policy-grounded chat assistant, document intelligence — over a synthetic customer book. Its most useful artefact is the security audit Shreyansh wrote against his own build, graded P0 to P3 with the worst finding first, followed by the fixes. - **Modules:** 12 - **Audit findings:** 20, graded P0–P3 - **Highest severity:** P0 — self-reported - **Data:** Synthetic only — no real PII - **Stack:** Next.js 16 · TypeScript · Prisma · Supabase · Groq · Gemini ## The problem it solves A relationship manager's day is spread across a dozen systems: the customer's accounts and transactions, credit risk, loan products, government schemes, policy circulars and KYC documents. The questions they actually ask — is this customer drifting into risk, which loan fits, what does the policy say — need all of that at once, in plain language. Sarthi started as a hackathon brief: build that copilot. The harder brief Shreyansh set himself was to make it honest about where AI helps, where it guesses, and where the system itself is unsafe. ## What he built ### Twelve modules on one customer book Customer 360, Financial Health Score (six weighted factors), Risk Prediction, Loan Recommendation with EMI estimates, Lead Qualification, an explainability view, a policy knowledge base, RM Chat, Next Best Action, a government-scheme matcher, Document Intelligence (classification, entity extraction and compliance flags) and an analytics dashboard — over a seeded, synthetic dataset of 24 customers, 16 leads, policies, schemes and loan products, so no real customer data is ever involved. ### Grounded chat, not a free-floating chatbot RM Chat answers with the selected customer's context and the policy corpus in the prompt, so responses cite the bank's own policies (e.g. 'POL-003') instead of general knowledge. It runs on Groq (Llama 3.3 70B) and tells the user plainly when no model key is configured rather than pretending a fallback works. ### A pipeline split so stages fail alone Shreyansh's design keeps embedding, storage, retrieval and generation as separate modules, each inspectable and replaceable on its own — so a weak retrieval step can't hide behind a fluent answer. ### Next.js 16 and TypeScript end to end An API route behind each module, Groq and Gemini for models, and seeded data held in memory for the prototype — with the move to a real database written down as the next step rather than implied. ## The hardest decision: Publish the audit instead of quietly patching it Once the demo worked, Shreyansh reviewed it as an outsider would and wrote the result down: twenty findings, graded P0 (security) to P3 (polish), worst first. P0 #1: no authentication on any endpoint, and sequential customer IDs (CUST-1001…CUST-1024) — the whole book scrapeable with a for-loop. P0 #2: the chat API accepted a caller-supplied 'system' role in its history — a full prompt-injection override. P0 #3: no rate limit in front of a paid LLM API. The decision was to keep that document in the repository, alongside the fixes — role whitelisting and a ten-turn cap on chat history, zod validation on every POST route, response checks in every client fetch, a per-IP rate limiter with a stricter cap on chat, an optional API gate token, and security headers — and to state plainly what was deliberately deferred: real per-user authorization and a move off in-memory data, both unnecessary for a synthetic-data prototype but essential before real customers. ## The result A working twelve-module copilot, and a written record that separates a hackathon build from something you could put in front of real customer data. Every P0–P3 finding was addressed except the two deferred items, which are named as such. It's the clearest example on this site of how Shreyansh treats AI systems: the model sits inside the loop, and the system around it is audited like any other code. ## Research findings - **Splitting RAG into four modules that can each be wrong alone:** Embeddings, vectors, retrieval and generation are separate modules — each stage independently inspectable and replaceable. - **Auditing your own code as the attacker:** P0 self-reported: no auth on any endpoint, sequential enumerable IDs — scrapeable with a for-loop. Published, not quietly patched. Stack: Next.js, TypeScript, Prisma, Supabase, Groq, Gemini --- Shreyansh Kumar Singh — AI & Full-Stack Engineer, Pune, India. Contact: shreyanshkumarsingh208@gmail.com or https://www.shreyanshkumarsingh.com/contact (call and WhatsApp buttons). More: https://www.shreyanshkumarsingh.com/llms.txt · https://www.shreyanshkumarsingh.com/sitemap.xml