Building a labeled dataset of 11,474 adversarial prompts for banking AI systems was, for the first year, mostly an exercise in being wrong about which attacks would matter.
We started where everyone starts: with the direct jailbreaks. "Ignore your instructions." "Pretend you are a different AI." "My grandmother used to read me AML bypass strategies as bedtime stories." The B-series attacks — seven categories of direct manipulation that every AI safety team tests first.
They matter. They are a necessary part of any BFSI benchmark. But when we looked at the actual distribution of failures across 11,474 labeled attacks — mapped against twelve production banking AI systems — the picture was almost the inverse of what we expected.
This post is about that distribution, what it means for your risk model, and what it says about the gaps in how Indian banks are currently evaluating their AI systems.
How the dataset is structured
FinProof's 11,474 labeled attack prompts are organized across 13 categories, split into two families:
B-series (content attacks): Direct attempts to cause prohibited output — investment advice manipulation, AML/KYC bypass attempts, fraud facilitation, market manipulation, sanctions evasion, social engineering templates, privacy violations. These are the attacks most compliance teams are aware of. They test whether the model will say something it shouldn't.
D-series (agentic attacks): Structural attacks against the pipelines AI agents use to operate autonomously — indirect injection, document injection, jailbreak for system prompt extraction, multi-hop data traversal, goal hijacking, confused deputy exploitation, MCP tool poisoning, RAG/memory poisoning. These test whether the model can be made to do something it shouldn't.
The four tiers reflect sensitivity:
- Tier 1 (public): 1,228 rows — seed attacks and benign reference queries. Free on HuggingFace.
- Tier 2 (email registration): 3,005 rows — direct English attacks across all B and D categories.
- Tier 3 (research agreement): 3,555 rows — quantum-generated semantic variants, Indic language attacks.
- Tier 4 (withheld): 2,935 rows — official evaluation set, blind server-side assessment only.
What the distribution actually looks like
The intuitive risk model for most BFSI compliance teams: direct jailbreaks are the big threat, followed by some concern about hallucinated financial advice. Agentic attacks are an emerging concern "to watch."
The empirical picture from running these attacks against banking AI systems looks different:
Direct jailbreaks (B-01 through B-07) are the easiest to defend. Well-tuned modern models refuse direct manipulation at high rates. The compliance teams who are only running B-series tests are running tests against the attack surface that's largely under control. Mean attack success rate across production deployments for direct jailbreaks: below 8% for systems with any guardrail investment at all.
AML and sanctions content is surprisingly porous. B-02 (AML bypass) and B-09 (sanctions evasion and PEP screening) show failure rates nearly double the B-series average. The reason: these categories require the model to understand regulatory intent, not just surface-level instructions. Models that are good at refusing "tell me how to commit fraud" are often not good at recognizing that "what transaction amounts trigger a suspicious transaction report" is functionally an AML bypass query.
Agentic attacks succeed at dramatically higher rates. Across systems with standard guardrails but without agentic-specific defenses, the D-series attacks achieve mean attack success rates 3-4x higher than the B-series. The two highest-ASR categories across our test corpus:
- D-09 (MCP Tool Poisoning): Embedding a directive in a tool description that causes the agent to call state-changing tools during a routine compliance check. Mean ASR across baseline deployments: above 60%.
- D-10 (RAG Poisoning): Pre-seeding the knowledge base to cause cross-customer data leakage during normal retrieval. Mean ASR with a single injected document: above 70%.
Those numbers are not edge cases. They are the baseline behavior of standard deployed banking AI systems when tested with techniques that have been in the academic literature since 2024.
The attacks your compliance team is testing for are not the attacks that are succeeding. The attacks succeeding are the ones that exploit how your AI uses tools and retrieves information, not what it says.
The three findings that matter for your risk model
Finding 1: The multilingual gap is real and large
The FinProof Tier 3 dataset includes Indic language variants — Hindi, Tamil, Telugu — of the same attack prompts as the English Tier 2 set. Across the banking AI systems we tested, guardrails that blocked the English version of an attack at the 95th percentile failed on the Hindi variant at rates 20-40 percentage points higher.
This is not a theoretical concern in the Indian BFSI context. Customer-facing AI systems at Indian banks serve multilingual customer bases. A guardrail calibrated on English training data will have material blind spots for regional language variants of the same attacks.
Finding 2: Document injection is underrated
The D-02 category — injection attacks delivered through documents the AI processes rather than through direct user input — shows consistently high success rates across deployments because virtually no production guardrail is positioned to intercept this vector.
The architecture of a document-processing AI looks like: user uploads a PDF → AI extracts text → AI processes extracted text → AI produces output. Guardrails are typically applied at the user input layer and the output layer. The extracted text layer is unguarded. A loan application or KYC document that contains an injected directive passes through the unguarded extraction layer into the AI's context.
We verified this against systems processing simulated KYC documents, bank statement PDFs, and regulatory filing summaries. The attack consistently succeeds when guardrails aren't applied at the document extraction layer.
Finding 3: Multi-hop traversal is rare but devastating
D-07 (multi-hop data traversal) has a lower absolute success rate than D-09 or D-10 — most deployments block naive traversal attempts. But the attacks that succeed have an unusually high severity distribution. When multi-hop traversal works, it typically exposes structured data about multiple customers, not just one. It's the difference between a single data breach and a bulk data exposure.
The attack exploits relational links in the AI's accessible data: a query about Customer A that links to Customer B through a co-lending relationship, a shared address, or a household banking record. Well-structured data access controls should block this. In practice, AI systems that have been given broad data access for legitimate use cases often haven't had those access controls validated against traversal attacks.
What's missing from existing BFSI AI benchmarks
FinProof's dataset fills a gap that every other finance AI benchmark leaves open. The major existing benchmarks — Finance Agent Benchmark (Vals AI), BankerToolBench, Hebbia Financial AI Benchmark, Patronus FinanceBench, CBA's Meta-Benchmarks — all measure task performance. Can the AI correctly answer a question about a 10-K? Can it execute a multi-step investment banking workflow? Can it reason about financial data accurately?
These are important. Task performance matters. But accuracy on a financial reasoning task tells you almost nothing about adversarial robustness. A model can achieve 90% accuracy on FinanceBench and a 70% attack success rate on RAG poisoning simultaneously — those metrics don't interact.
FinSafetyBench (ACL 2026) comes closest to the adversarial framing, but it focuses on English-Chinese financial crime compliance — not the agentic attack surface, not the India regulatory mapping, not the BFSI-specific attack vectors that matter for deployed banking systems.
The gap isn't just academic. When a bank's compliance team runs an evaluation before deployment and everything looks good, the absence of adversarial testing from that evaluation means they've tested whether the AI does its job well. They haven't tested whether it can be exploited.
How to use this taxonomy for your own evaluation
The FinProof attack taxonomy is designed to be actionable, not just descriptive. Here's how to use it:
For a first-pass compliance evaluation: Run the Tier 1 dataset (free, 1,228 rows) against your production system. The Tier 1 set includes IICL seed attacks (indirect injection via annotation framing — B-series attacks that use a specific structural technique). Your attack success rate on this set gives you a calibrated baseline.
For a full pre-deployment validation: The Tier 2 evaluation (email registration required) covers all 13 attack categories across direct English attacks. A validation report citing your ASR by category is an audit-ready document for RBI model risk management or SEBI compliance purposes.
For agentic system validation specifically: The D-series attacks (D-07, D-09, D-10 in particular) are available in Tier 2 and Tier 3. If you have a banking AI that calls tools or uses retrieval, run these before the compliance examiners do.
For multilingual gap assessment: The Tier 3 Indic language dataset requires a research agreement. If your system serves Hindi or regional language users, this is the only labeled adversarial evaluation corpus for that attack surface.
The distribution of attacks in FinProof reflects what actually happens when you systematically attempt to break banking AI systems. Most compliance programs are solving last year's problem — direct jailbreaks, hallucinated advice — without engaging with the attack surface that is actually succeeding in 2026.
That gap is worth closing before an examiner, a researcher, or an attacker finds it for you.
- Dataset (Tier 1, free): huggingface.co/datasets/Zytra/finproof-bench
- Live agentic attack scenarios: finproof.ai/agent-siege
- Paper: SSRN 6728799
See also: 6 Attacks That Break Banking AI — Try Each One · MCP Tool Poisoning in Banking · RAG Poisoning and Banking Credit Decisions