Praheri is a sovereign financial-crime platform built on a typed ontology — a living digital twin of accounts, transactions, claims and companies. A local Llama traverses it to expose fraud rings, drafts the regulatory report, and proposes governed actions a human approves — every step audited, nothing leaving the building. We're looking for one design partner to harden it on real workflows — and we think that's Jio Financial Services.
The console runs on-prem — by design, it never leaves your machine. Run it locally →
RBI data-localization makes the cloud copilot a non-starter — and a black-box API can't be audited, fine-tuned, or trusted with a freeze decision. Praheri is the alternative: the entire intelligence layer runs on-prem on open-weight Llama, over a typed model of the institution's own world, with a human in the loop on every consequential action.
Borrowing Palantir's framing: the ontology is a semantic layer — the nouns and how they relate — and a kinetic layer — how decisions are written back as governed actions. Your data stops being rows in a table and becomes a live, connected map of reality that both analysts and AI can reason over.
Every real-world entity becomes a typed object — an Account, a Transaction, a Claim, a Company — carrying its own properties. An object type is the table; an object is the row.
Relationships are first-class and typed — sent →, serviced_by →, owns →. The links are the structure, so tracing a ring six hops out is a native graph traversal, not a recursive SQL nightmare.
The model never mutates data directly. It proposes an action — freeze an account, file an STR, escalate a KYC review — which routes to a human approver and, on approval, is applied and audited. This is the closed loop: read the world → decide → act → the record updates.
Ontology-Augmented Generation feeds the model structured, typed, linked objects — not prose that mentions them. So the model reasons over ground-truth structure, and every claim it makes cites a real object ID. The fraud ring isn't described; it's traversed.
Ten fuzzy case notes are retrieved as prose. The model re-parses English to infer who connects to whom — and may invent a link that was never written, or miss one that was.
The same ring is retrieved as typed objects with their actual links. The model follows the edges, sees the cycle, and names every node by ID. The structure is the evidence.
We chose Banking, Financial Services & Insurance deliberately — it is where the pain, the regulation, and the data-shape all point at the same architecture. Three forces just converged:
Laundering, staged-claim rings and shell ownership are, by definition, patterns of connection — not properties of any single row. A relationship-native ontology is the correct data model for the problem; flat tables and text chunks are not.
RBI data-localization and the DPDP Act make a frontier-cloud copilot a non-starter for this data. BFSI can't send customer transactions to a US API — so the only compliant path is on-prem, open-weight, auditable. That constraint is our moat.
Llama-class models can now classify a typology and draft a filing-grade narrative on a single on-prem box. The capability that used to require a frontier API now runs inside the building — for the first time, sovereign and capable are no longer a trade-off.
Classic graph algorithms and rules engines are better than any LLM at finding a ring — so that's exactly what does the detection here, in deterministic Python. The Llama earns its place on the two jobs traditional ML structurally cannot do. This is why the recommendation is trustworthy and the platform generalizes.
Ring traversal, structuring / circular-flow / shared-device detection and the risk floor are pure code — reproducible, auditable, no hallucination. A fired signal is a confirmed typology the model may escalate but can never downgrade to CLEAR.
1 · It writes the report a human can sign. Graph algorithms output a diagram and a risk score. But the compliance officer has to file an actual written report — plain English that names each account and transaction and explains, in words, why it's suspicious. Writing that report, grounded in the bank's own rules, is exactly what an LLM is good at and a graph model can't do. (A filing-grade STR for FIU-IND, citing real object IDs.)
2 · One brain works for every department. A traditional fraud model must be custom-built and re-trained for each area — one for banking, a separate one for insurance, another for lending — each needing its own data and its own team. The same Llama handles all of them by just swapping the settings file. No retraining, no new team per sector. (Zero per-domain feature engineering or labelled training set.)
The whole stack runs on-prem on open-weight Llama. Compliance by construction, not by promise.
The model proposes; a human approves; everything is audited. No mutation without a governed action.
Swap the ontology cartridge and a new sector lights up — zero engine code changed.
This pipeline is unchanged across all verticals.
Each sector is a configuration — typed objects, the signals to detect, the governed actions a human approves. The engine never changes. AML and Insurance are where we'd start with JFS — they sit directly on Jio Payments Bank, Jio Finance and Jio Insurance Broking. The other four prove the same engine already reaches across the group.
JFS is the rare institution whose group spans every sector this engine already runs — payments, lending, insurance, asset management — under one roof, at Reliance scale, greenfield enough to build compliance-native rather than retrofit it. We're not selling a finished product; we're proposing a design partnership to harden Phase 1 on your real AML and insurance workflows.
Retail money movement at Reliance scale is the natural home of mule networks and structuring. → Praheri AML: expose the ring, draft the STR for FIU-IND, propose the freeze — human-approved, audited.
Claims exposure is where organized fraud erodes the loss ratio. → Praheri Insurance SIU: surface staged-accident and garage-collusion rings across otherwise-unrelated claims before payout.
As the group expands, the same engine extends to wealth suitability, corporate UBO resolution and procurement controls — zero engine code per sector. One platform, the whole JFS surface.
Deploy on-prem against a masked slice of Jio Payments Bank transactions. Prove the ring-to-STR loop on real workflow shape. Success metric agreed up front. No data leaves JFS.
Iterate the two Phase-1 cartridges on live JFS ontology and MLRO/SIU feedback. Wire the real approval + audit workflow. This is where we co-build — your analysts shape the product.
Extend the same engine to Jio Finance lending EWS, JioBlackRock suitability, group UBO and procurement — each a config cartridge, not a new build. One sovereign intelligence layer for all of JFS.
The live console runs the full loop: triage an alert, traverse the ontology, expose the fraud ring, draft the report, propose a freeze, approve it as the MLRO, and read the audit trail — all on-prem, with no network egress.
Sovereign by design — the console can't be hosted on a public cloud without breaking the premise. It runs on your own machine, with no network egress.
The console is open source and runs entirely on-prem on open-weight Llama via Ollama. Clone it, point it at a local model, and the full investigation loop runs with no network calls.
# 1 · clone the repo git clone https://github.com/surajsrivastava94/praheri-sovereign-aip.git cd praheri-sovereign-aip # 2 · python env + dependencies (Python 3.11+) python -m venv .venv && source .venv/bin/activate pip install -r requirements.txt # 3 · pull the open-weight models, then serve them locally ollama pull llama3.1:8b ollama pull nomic-embed-text ollama serve # 4 · generate the synthetic bank + planted fraud rings python -m praheri.generate python -m praheri.generate_verticals # 5 · launch the console → http://localhost:8501 streamlit run app/streamlit_app.py