The Short Answer
NPCI unveiled FiMI Banking at Global Fintech Fest on 10 September 2026, announced with HDFC Bank rather than deployed, and its weights are not published: NPCI's Hugging Face organisation lists zero models. The deployment target is Gemma 4 E4B, 4.5B effective parameters and 16 GB of BF16 weights, which fits on one 80 GB GPU inside a bank. With ibl.ai you own all the code and the data.
The size is the story. The word "deployed" and the word "open-source" are both doing work they have not earned yet.
Did NPCI deploy FiMI Banking, or announce it?
It announced it, on 10 September 2026, at the Global Fintech Fest, held 8–11 September at the Jio World Centre in Mumbai.
NPCI presented FiMI Banking as a "sovereign compact model" for Indian retail banking and named HDFC Bank as the partner it will work with to develop the model further, per Retail Banker International.
The accompanying technical paper from the NPCI AI Research Team, submitted 3 September 2026, describes a controlled Indian retail-banking evaluation setting. It makes no claim of a live bank deployment.
There is a FiMI in production, and it is a different model. The original FiMI launched in February 2026 and powers the UPI Help Assistant in English, Hindi, Telugu and Bengali, reported by The Tribune on 17 February 2026.
That one is not small. Its paper describes an adaptation of Mistral Small 24B, continuously pre-trained on 68 billion tokens of financial, multilingual and synthetic data.
So the deployed FiMI is 24B, and the 4B-class FiMI is the one that was announced. Conflating them produces a claim that is wrong in both directions.
Is FiMI open source, and what did NPCI actually publish?
The benchmarks are open. The model is not.
NPCI is open-sourcing the benchmarks, evaluation sets and technical report used to measure how banking agents perform — IndicBankBench, 799 scripted multi-step cases across six retail-banking areas, and a Tau-style agentic benchmark of 1,000 tasks across 50 scenario types, per Crypto Briefing.
Both are published. NPCI's GitHub organisation carries IndicBankBench under MIT and TauIndianBankBench, alongside the AiNxt agent tooling.
The weights are not. NPCI's Hugging Face organisation lists zero models and three datasets: IndicBankBench, tau-indian-banking and nemo-gym-indian-banking.
The base model is open. Gemma 4 E4B is Apache-2.0. NPCI's continued training on top of it is not something anyone outside NPCI and HDFC can download today.
That distinction matters for procurement. An Apache-2.0 base you can fine-tune yourself is leverage. A published benchmark is a useful yardstick. Neither is a model you can run.
It also matters that FiMI Banking was not built from scratch. NPCI post-trained an openly published Google model: "We select a small open model so that it can be deployed within bank-controlled infrastructure. The target is Gemma 4 E4B, with 4.5B effective parameters."
That is the stronger version of the story, not the weaker one. A central payments body got a deployable domain model out of post-training, rather than funding a nation-scale pre-training run — which is a path available to any institution with domain data and a modest GPU budget.
What does "fits on one server" mean in gigabytes?
It means 16 GB of weights, which is small enough that the interesting constraint stops being the GPU.
Gemma 4 E4B carries 8B total parameters with embeddings and 4.5B effective, using per-layer embeddings, with a 128K context window. The BF16 checkpoint on Hugging Face is a single 16 GB model.safetensors file.
NPCI's paper is explicit about the intent: the model is "intended to run on hardware controlled by the bank, including in fully air-gapped settings," and states that a 7k-token session uses roughly 80 MiB of KV cache, so an 80 GB GPU can hold the model and support hundreds of concurrent sessions.
The paper is equally explicit about who holds the artefact: "Banks therefore control the model weights, and they can specialize the model for their own products and tool contracts."
The "no cloud, no cross-border transfer" framing circulating about FiMI is therefore NPCI's own design claim, not an outside inference. What has not happened is a bank running it in production.
Set that against the frontier tier. Two weeks earlier, Tencent open-sourced Hy4 preview under Apache-2.0: 770B total parameters, 49B active, and roughly 1.56 TB of BF16 weights.
| Model | Parameters | BF16 weights | What serves it |
|---|---|---|---|
| Gemma 4 E4B (FiMI Banking target) | 8B total / 4.5B effective | 16 GB | One 80 GB GPU, hundreds of concurrent sessions |
| Mistral Small 24B (original FiMI base) | 24B | ~48 GB | Still one 80 GB GPU |
| Tencent Hy4 preview | 770B total / 49B active | 1,560 GB | Not an 8-GPU H100 node, which holds 640 GB |
The 24B row is arithmetic at two bytes per parameter, not a published file size. The other two are measured: 16 GB from the Gemma repository, 1.56 TB from Tencent's.
Why does a model that fits change what a regulated bank can procure?
Because the deployment question stops being a cluster build and becomes a line item in existing capacity.
A frontier checkpoint that needs more than 640 GB of aggregate GPU memory is a procurement of racks, power, cooling and an interconnect. Very few regulated institutions will do that for a customer-support agent, so they rent the model instead, and the data leaves.
A 16 GB checkpoint runs on hardware a mid-sized bank already has. That single fact changes four things at once: it can sit inside the perimeter, it can be air-gapped, it can be audited in place, and it can be replicated per region without renegotiating a cloud contract.
The accuracy trade is smaller than the size gap suggests. NPCI reports its post-trained E4B reaching 0.697 average reward against a 0.610 baseline, passing a 12B reference model's 0.690 while generating about 29% fewer tokens during serving.
Fewer tokens per resolved task is a cost effect as well as a latency one, and it compounds in exactly the high-volume support workloads a payments network cares about.
The safety numbers move further than the capability ones. Post-training raises out-of-scope refusal from 52% to 80%.
For a regulated deployment that is the more consequential figure. An agent that reliably declines what it is not authorised to handle is the precondition for letting it handle anything.
This is the practical form of the argument India has been making structurally, which we covered in India's public AI rails. Rails you run are rails you can govern. A model that fits on your own server is the first thing that makes running them possible.
How does ibl.ai run small models inside a bank's perimeter?
By putting the whole platform where the data already is, and treating the model as a swappable component.
With ibl.ai you own all the code and the data.
The platform self-hosts on the institution's own infrastructure with full source code, is model-agnostic across any LLM — a 4B model served locally on vLLM, an open-weight 24B, or a frontier API when the workload justifies it — is usage-based with no per-seat pricing, and can deploy anywhere from your own cloud to on-premise, GovCloud or a fully air-gapped network.
Per-seat licensing is the wrong shape for this workload specifically. A support agent handling millions of payment queries has almost no relationship between headcount and volume, so a price that tracks employees prices the wrong thing.
The model-agnostic part is what makes the fit argument durable. When the next 4B-class model beats today's, swapping it is a registry entry rather than a migration, and the compliance posture does not change because nothing moved.
1.6M+ users across 400+ organizations run the platform this way, including NVIDIA, MIT, and Syracuse University.
ibl.ai is family-owned and operated from New York, NY.
Related reading: India is building public AI rails the way it built UPI — the structural argument this model is the concrete case of; and Tencent's 770B Hy4 — the same week's release at the opposite end of the size range.
Sources: the 10 September unveiling, the HDFC Bank partnership and the "sovereign compact model" framing from Retail Banker International; the Global Fintech Festival 2026 setting, the benchmark counts and the benchmarks-not-weights scope of the open-sourcing from Crypto Briefing; the fest's 8–11 September dates and Jio World Centre, Mumbai venue from Global Fintech Fest; the E4B deployment target, the air-gapped intent, the 80 MiB KV-cache and 80 GB GPU figures and the 0.697/0.610/0.690 rewards from the FiMI Banking paper; the Mistral Small 24B base and 68B training tokens of the original model from the February FiMI paper; its production status in UPI Help from The Tribune; the published repositories from NPCI on GitHub and NPCI on Hugging Face; the 8B/4.5B parameter split, Apache-2.0 licence and 16 GB checkpoint from google/gemma-4-E4B-it.