Does Banking Co-pilot let a language model make credit decisions?

No. Every score — financial health, risk probability, loan eligibility, lead quality and next best action — is computed by a deterministic engine with named, weighted factors. No language model touches any of them. LLMs are confined to conversation, synthesising a cited answer from retrieved bank policy, and reading a document image.

Why does the API return 404 instead of 403 for another Relationship Manager's customer?

Because 403 Forbidden confirms the record exists. An attacker probing sequential customer ids could map the bank's entire customer ID space from the difference between a 403 and a 404, without reading any record. Returning 404 for both 'does not exist' and 'not yours' makes the two cases indistinguishable and the enumeration worthless.

Is Banking Co-pilot built on real customer data?

No. The dataset is entirely synthetic — 24 generated customers across 4 Relationship Managers, 8 policy documents and 8 government schemes. No real customer data is used anywhere. The security controls are built to production quality so the platform is ready for real, governed data.

How was the Banking Co-pilot secured?

Through five hardening phases driven by three independent audits: per-relationship-manager data isolation, insecure direct object references closed by returning 404 rather than 403, PII masking, an append-only audit trail, row-level security, and prompt-injection isolation with validated citations. It carries 38 automated security tests, 17 of which drive a live server.

Banking · 12 modules · live

Banking Co-pilot

Banking Co-pilot is an AI assistant for retail-banking relationship managers, spanning 12 modules across customer analytics, decisioning, grounded policy answers and document verification. Every score is deterministic and explainable — no language model takes a credit decision. It carries 38 automated security tests and runs entirely on synthetic data.

An AI copilot for bank Relationship Managers — twelve modules turning scattered customer data and bank policy into decisions you can defend.

Deterministic scoring engines, retrieval-augmented answers over bank policy with validated citations, and vision-based document verification — behind authentication, per-RM data isolation and PII masking. Built as a production-grade reference implementation on entirely synthetic data.

Next.js 16Auth.js v5Supabase pgvectorGroq + Gemini38 security testsSynthetic data

Open the live site Jump to the security model

bankingcopilot.houseofnamus.com — Customer 360

Customer 360 — profile, accounts, transactions and risk signals in one view, the lookup that otherwise costs an RM four systems and a phone call. The copilot itself sits behind sign-in; the public site is open, the twelve modules are not.

modules across customer, decisioning, assistant and operations

API routes, every one session-gated

~0.0K

lines of TypeScript, 0 type errors

security tests passing — 21 unit, 17 live integration

security phases, driven by 3 independent audits

01Why it exists

The Relationship Manager becomes the integration layer.

An RM covering a book of customers is asked to answer, quickly: what is going on with this customer across every product they hold; are they a risk, and can I say why in a sentence compliance accepts; what should I offer them next, and are they actually eligible; does this Aadhaar card match the person on file; and what does bank policy actually say — and where does it say it.

Each answer lives in a different system. The RM stitches them together from memory and instinct — slow, inconsistent between RMs, and, when the reasoning behind a decision cannot be reconstructed afterwards, a regulatory problem.

The wedge

Not “add AI to banking”. Collapse the lookup time, and make the reasoning inspectable.

02What it does

Twelve modules. Three where the difficulty is the point.

Customer, Decisioning, Assistant and Operations — all inside one authenticated shell, alongside the Customer 360 view above. These three are where a technical reviewer will want to look, because each has to survive being questioned rather than just displayed.

Explainable AI

Which factor moved the decision, and by how much

SHAP-style feature attribution over the loan decision: a force plot from base rate to final probability, and a waterfall naming every contributing factor. This is what makes an approval defensible six months later, in front of someone who was not in the room.

Explainable AI module showing an Approve decision at 98% confidence, a base-to-final force plot, and a feature attribution waterfall ranking CIBIL score, monthly income, EMI burden and credit utilisation

Financial Health Score

0–900, defensible point by point

Six weighted factors — savings ratio, credit utilisation, EMI burden, financial stability, product diversification, digital engagement — each with its own weight, band and contribution. Deterministic: the same inputs always produce the same score.

Financial Health Score module showing a 585/900 score rated Fair, a six-axis radar of factor breakdown, and per-factor cards with weights and contributions

Risk Prediction

12-month default probability with named drivers

A default probability, an SMA stage, and an attribution chart splitting what raises the risk from what mitigates it. Red, amber and green appear here on purpose — in this product they are reserved for meaning, which is why the brand is petrol and brass instead.

Risk Prediction module showing a 2.0% twelve-month default probability rated Low, a risk gauge, an RM recommendation, and a risk-driver attribution chart

03The rest of the shell

Eight more, in the same shell.

Next Best Action module listing six prioritised recommendations across a customer book, each with a rationale, a channel, a due window and an expected uplift — Next Best Action — Prioritised P0–P3 recommendations across the whole book, each with its reason and its expected effect.

Analytics dashboard showing total AUM, six total customers, average health score and high-risk count, with customer-segment, lead-pipeline, health-score and risk-band distribution charts — Analytics — Portfolio KPIs and distributions. Total customers reads 6, not 24 — this RM is seeing her own book, and the scoping is visible in the numbers.

Lead Qualification module showing a six-column Kanban pipeline — New, Qualified, Proposal, Negotiation, Won, Lost — with scored lead cards and stage totals — Lead Qualification — A scored Kanban pipeline with auto-stage progression, from New through to Won or Lost.

Government Scheme Matcher showing eight central schemes ranked by match score, each with benefits, maximum subsidy and the eligibility criteria met or missed — Government Scheme Matcher — Eligibility matched across eight central welfare schemes, with the criteria met and missed shown per scheme.

Not pictured: RAG Knowledge Base — hybrid retrieval, vector plus keyword fused by Reciprocal Rank Fusion, answering with inline [POL-001] citations validated against the documents actually retrieved. Document Intelligence — upload an Aadhaar, PAN, bank statement or salary slip; it classifies, extracts by vision OCR, validates (including the Verhoeff checksum a real Aadhaar number must satisfy) and cross-checks against the customer on file. Loan Recommendation and RM Chat complete the twelve.

04Three decisions

A feature list is forgettable.

These three are specific decisions with reasoning behind them — and the reasoning is the part worth reading.

01Access control

Returning 404 instead of 403

When a Relationship Manager requests a customer outside their own book, the API returns 404 Not Found — not 403 Forbidden.

403 is the intuitive answer and it is the wrong one. “Forbidden” confirms the record exists. An attacker walking CUST-1001, CUST-1002, CUST-1003 learns the entire customer ID space from the difference between the two responses, without ever reading a record. Returning 404 for both “doesn't exist” and “not yours” makes those cases indistinguishable and the enumeration worthless.

There is a second layer. Next.js has shipped middleware-authorization-bypass advisories, so authorization is never left to the edge proxy alone — every route handler re-checks. The pure predicates live in their own module, with no framework imports, so they can be unit-tested away from any request plumbing.

02Where the AI is allowed

The model deliberately does not decide

Every score in the product — health, risk, loan eligibility, lead quality, next best action — is computed by a deterministic engine. No language model touches any of them.

That is a constraint, not a limitation. A bank cannot take a credit decision it is unable to reconstruct; “the model said so” does not survive an audit. Deterministic engines mean identical inputs always produce an identical score, every point is attributable to a named factor, and the reasoning still stands six months later.

Language models are confined to the three jobs where language genuinely helps: conversation, synthesising a cited answer from retrieved policy, and reading a document image. In a field whose default move is to put an LLM in front of everything, choosing not to is the harder call.

03Design

Colour as information architecture

The brand palette is petrol blue and brass. Neither is red, amber, or green — and that is the whole point.

In a product whose central claim is explainable risk, those three carry meaning: risk bands, health scores, KYC state. If the brand accent were also green, a user would have to work out whether a coloured element meant “brand” or “good”. So the status band is reserved for meaning and the brand sits outside it. Chart gridlines and axes are slate rather than brand-tinted for the same reason — they are structure, not signal.

The palette carries an accessibility constraint in the token layer too. Brass is 3.0:1 on white, which fails WCAG AA for small text. Rather than lighten the brand, a separate darker step carries brass-coloured text at 4.8:1. The constraint resolves in the tokens instead of compromising the design.

05Security posture

The security model is real,
not decorative.

RM tooling touches the most sensitive data a bank holds, so it was built accordingly: every route session-gated, every RM scoped to their own book, out-of-book access returning 404 rather than 403 so record ids cannot be enumerated, PII masked at the boundary, and an append-only audit trail behind it. Hardened through five structured phases driven by three independent audits — a VAPT report, a full audit and a deep audit — with every finding remediated and verified.

The one number that matters

17 integration tests drive a live server through the real authentication flow — proving per-RM isolation, IDOR handling and PII masking against a running application, not against mocks. 21 unit tests cover the pure predicates and the masking functions alongside them. The suite has already caught a real regression: raw phone and email leaking through the document cross-check response.

Never trust a single gate.

Next.js has a documented history of middleware-authorization-bypass advisories, so the edge proxy is treated as a fast reject and never as the authority. Every route handler independently re-authenticates and re-authorizes. Four layers, so a weakness in any one of them does not become a breach.

Edge proxy

Session gating — no session, no data: 401 or a redirect to login
Per-user rate limiting, returning 429 with Retry-After
CSP, HSTS, frame-deny and nosniff on every single response

Treated as a fast reject, never as the authority.

In-handler authorization

Re-authenticates and re-authorizes inside every route handler
Per-RM book scoping; 404-not-403 on out-of-book access
Role gate — knowledge-base ingest and corpus writes are admin-only

Pure decision logic, no framework imports, unit-tested in isolation.

Data & AI protection

PII masked at the boundary; raw OCR text redacted before it returns
Retrieved policy and uploads treated as data, never as instructions
Magic-byte upload validation with EXIF stripping
Append-only audit trail behind every sensitive action

Load, then authorize, then project — never filter after the fact.

Platform

Supabase Row-Level Security on users, audit log and RAG chunks
anon access revoked; the service-role key never leaves the server
Build fails on type errors by design — currently 0

Least privilege, all the way down to the database role.

Closing IDOR deliberately

404 is the right answer.

An access-control decision is also an information-disclosure decision. The status code you return to a request you are refusing is itself data — and if it differs from the one you return for a record that does not exist, you have built an oracle.

The intuitive answer

GET /api/customers/1001

403

Forbidden. The record exists — you just can't have it.

GET /api/customers/9999

404

Not found. No such record.

Two different responses. Walk the id space and the difference between them hands you every valid customer id in the bank — without reading a single record.

What it actually returns

GET /api/customers/1001

404

Out of your book. Indistinguishable from absent.

GET /api/customers/9999

404

Genuinely absent. Indistinguishable from out of book.

One response. There is no signal left to enumerate against.

The control catalogue.

Six groups, each enforced in code rather than described in a policy document.

Authentication

Auth.js v5, credentials provider, stateless JWT sessions
bcrypt password hashing — never stored or logged in plaintext
Timing-attack resistant: an unknown email still runs a bcrypt compare against a dummy hash, so response time never reveals whether an account exists
HttpOnly, Secure, SameSite cookies — which also gives baseline CSRF protection
Four roles: rm, manager, compliance, admin

Authorization & IDOR

Per-RM data isolation — an RM reaches only the customers in their own book
404, not 403, on out-of-book access, so customer ids cannot be enumerated
List endpoints filter through a single scoping function: portfolio, analytics, leads and next-best-actions are all restricted together
Load-then-authorize-then-project, so a full record is never returned and trimmed afterwards
Admin-gated ingest and corpus writes

PII protection

Aadhaar, PAN, account number, phone and email masked before the response leaves the server
Raw OCR text scrubbed; the unredacted text is not returned by default
No identifier written to logs in the clear — the audit trail carries ids and types only
The Customer 360 cross-check compares masked fields and returns Match / Partial / Mismatch without exposing the underlying numbers

AI & RAG hardening

Retrieved passages wrapped in delimiters and tagged official policy vs unverified upload
Client-supplied system roles stripped from chat history; history capped
The model is read-only and tool-less — it can take no action and touch no data
Every citation validated against the documents actually retrieved; unsupported ones flagged rather than trusted
Verified live: an injection query asking for the system prompt and keys is refused, with no leak

Uploads

Magic-byte validation — the real type is read from the bytes, not the spoofable MIME or filename
Strict allowlist: PDF, PNG, JPEG, WEBP and genuine UTF-8 text; anything else is a 415
Images re-encoded to strip EXIF and GPS metadata
Dimension and pixel caps against decompression bombs

Rate limiting & transport

Keyed by authenticated user id, so a signed-in caller cannot rotate X-Forwarded-For to escape the limit
Tiered buckets: 100/min general, 12/min on AI endpoints to protect LLM spend, 10/min on sign-in against brute force
Upstash Redis in production so limits survive across serverless instances
CSP with an allowlisted connect-src, HSTS preload, frame-ancestors none, nosniff, locked-down Permissions-Policy

Audit findings closed

All three audits described the same twenty issues under different ids. Every one is remediated and verified.

Critical

secrets in the tree, no auth, no authorization

closed

High

IDOR, unauthenticated ingest, prompt injection, KYC leak, SSRF sink

closed

Medium

rate-limit spoofing, upload controls, missing CSP, XSS, no audit log

closed

Low

CORS, security.txt, a key travelling in a URL

closed

What the suite asserts

Run against a live server, through the real sign-in flow.

Anonymous GET /api/customers401

RM requests a customer in their own book200

RM requests another RM's customer404

RM posts to /api/rag/ingest403

Admin lists customersall 24

Document response contains a raw PAN or phonenever

Designed against the frameworks that would audit it.

Alignment, not certification — the distinction matters, and it is stated here rather than blurred.

OWASP Top 10

Broken access control, cryptographic failures, injection, security misconfiguration, vulnerable components, SSRF and auth failures each have a named control against them.

DPDP Act 2023

Data minimisation, PII masking and redaction, purpose-limited processing, and an append-only accountability trail.

UIDAI (Aadhaar)

Aadhaar masked to XXXX-XXXX-1234 before leaving the server, never logged, and Verhoeff-checksum validated without retaining the full number.

RBI IT / Cyber-Security Framework

Role-based access control, audit logging, encryption in transit, least-privilege data access, and build-time security gates.

06Architecture & stack

Two providers, because one of them cannot do the job.

Frontend

Next.js 16 (App Router, Turbopack) · React 19 · TypeScript · Tailwind v4 · shadcn/ui · Recharts · Framer Motion

Groq openai/gpt-oss-120b for text · Google Gemini for embeddings and document vision · Supabase pgvector · transformers.js MiniLM as a local fallback

Platform

Auth.js v5 with JWT sessions · Supabase Postgres with Row-Level Security · Upstash Redis for distributed rate limiting · Vercel, or any Node 20+ host

Why the split

Groq has the fastest free-tier text inference, but no production vision model and no embeddings endpoint. Gemini covers both. So text generation routes to Groq, vision and embeddings to Gemini, unified behind a single interface with automatic fallback between them. The split is a consequence of what each provider can actually do — not of which one appeared first in a tutorial.

07Honest scope

What this is, and what it is not.

Stating a scope limit precisely is itself a signal. Three things belong on the page rather than in a footnote.

The dataset is entirely synthetic

24 generated customers across 4 Relationship Managers, 8 policy documents, 8 government schemes. No real customer data is used anywhere in the system. The controls are nonetheless built to production quality, so the platform is ready for real, governed data rather than needing to be rebuilt for it.

Authentication is demo credentials, not enterprise SSO

The role and RM-book model carries over to OIDC/SAML unchanged, but that swap has not been made. It is the first item on the backlog, alongside replacing the synthetic source and commissioning an authenticated pen-test retest.

It degrades instead of failing

Every external integration has a fallback: Gemini embeddings drop to a local MiniLM, the pgvector store drops to an in-memory one, generation drops to keyword-only retrieval. With no API keys configured at all, the application still runs.

Built on synthetic data, to production standards
— so the controls are ready for the real thing.

Open the live site All projects

A reference implementation and portfolio demonstration. Every customer, transaction and document in it is synthetic — no real banking data is used anywhere. Not a certified or independently accredited banking product.

Banking Co-pilot

The Relationship Manager becomes the integration layer.