India's NPCI Tested Bank AI Agents: Up to 12% of "Successes" Skipped Required Steps

National Payments Corporation of India (NPCI), the organization that runs the country's national payments infrastructure, has published a benchmark called TauIndianBankBench. It is a set of 1000 tasks in which a language model works as a retail-bank assistant. It talks to a customer played by another model and calls tools: blocking a card, closing a deposit, viewing a payment schedule. The authors' main finding: if you check only the final database state, as most similar tests do, then for every model 6.5–12.0% of "successful" sessions actually contain a procedural violation.

Why the final database isn't enough

Indian banks currently answer customers through FAQ pages and scripted chatbots with fixed replies. A model could respond faster and handle questions that aren't in the FAQ. But a bank can entrust it with the job only if it gives correct information and follows internal rules: a mistake hits the customer immediately.

The problem is that many mandatory steps in the rules write nothing to the database. Examples from the paper:

• before closing a deposit, the agent must get a closure calculation so the customer learns the size of the penalty; • before opening a deposit for an amount the account may not cover, the agent must look up the minimum-balance rule; • before blocking a card, the agent must check its status.

An agent that skipped all of this leaves exactly the same records in the database. A final-state check passes it, but the customer never receives the information those steps exist to provide. In India, many such steps are mandated by regulation: periodic KYC updates (customer identity checks), tax deducted at source (TDS) with exemption forms, and the legal eligibility conditions for government savings schemes.

Two checks instead of one

Each session gets two pass/fail verdicts:

• Final-state check. The reference chain of calls is replayed on an identical copy of the database, and then the records are compared. Before comparison, fields that vary from run to run are stripped out: generated numbers, references, free-text notes. • Action check. The agent must make every call in the reference chain, including reads, in any order. Any change the customer did not ask for fails the session. This holds even if the agent later rolled it back: while the change was in effect, the customer was already harmed.

A session counts as a success only if both checks pass. There is no partial credit: three calls out of four score zero, just like doing nothing. Scoring is fully deterministic, with no judge model, which can be biased toward long answers and its own style.

What the benchmark is made of

• A synthetic bank with 944 customers: accounts, cards, deposits, loans, standing instructions, KYC status, transaction history. • 34 tools: 33 service tools and one for handing the customer off to a human agent. Of the service tools, 20 only read data and 13 write (11 modify records, two place an order for a chequebook or a duplicate statement).

• 24 knowledge-base documents: payment limits, KYC updates, deposit insurance, tax on interest, payment refund deadlines, government schemes. • 50 task families in four categories: dependent multi-step tasks, tasks with a condition that must be noticed before acting (for example, the customer does not meet the requirements), rare operations, and simple control tasks. A call chain averages 3.

54 calls, from one to six. • Of the 1000 tasks, 962 require at least one read call and 114 require no writes at all.

There are several subsets: the full set of 1000 tasks, a lightweight set of 200 (four from each family), and a split into training and test parts so a model can be fine-tuned and evaluated fairly.

Humans did not write the tasks from scratch: a language model drafted them, and they were admitted through four filters. Opening customer messages must vary: no more than 40% of tasks in a family may start the same way, and there must be at least eight variants. For hard tasks, the chain must be at least three calls long. A task cannot land in both the training and test parts. The reference chain must pass both checks.

What the six models showed

The authors tested six open models, five of them from the Gemma 4 family. Results:

• for every model, 6.5–12.0% of sessions pass the final-state check even though the agent skipped a mandatory call or made an extra change; • for the three strongest models, most sessions that fail exactly one check are procedural violations that only the action check sees; • the weakest model shows the opposite pattern: it makes all the required calls but ends up with wrong records, and only the final-state check catches this; • scripted dummy agents pass no tasks; • on the control tasks, results do not depend on model size, while the three harder categories do separate the models.

To verify the comparison itself, the scorer implementation was cross-checked against an independent one on 600 recorded sessions, and the verdicts matched in every case. Before release, the package re-scored 5000 sessions and reproduced all results. The model ranking also held on a different setup for running the models.

What this means for banks and developers

Anyone choosing or fine-tuning a model for banking cannot look only at the final data state: some "successful" sessions actually broke the rulebook, and the customer did not receive mandatory information. The code, data and reference results are published on GitHub and Hugging Face. The limitations are also clear: the bank is synthetic, the customer is played by a model, and only open models were tested.