FraudBench: Stress-Testing Policy-Grounded Banking Agents Against Adaptive Fraud

# Stress-Testing Policy-Grounded Banking Agents Against Adaptive Fraud
Source: [https://arxiv.org/html/2608.18136](https://arxiv.org/html/2608.18136)
###### Abstract

Conversational agents now act for end users through tools while holding access to customer databases and internal policy documents that a caller can reach through dialogue alone\. Banking is the clearest case: the same agent that answers a question can also change contact details, reset a PIN, or move money, so ordinary customer service is inseparable from authorization, fraud detection, and policy compliance\. Existing financial\-fraud benchmarks classify static transactions or messages, and general agent\-safety benchmarks target prompt injection or generic harmful use; none test whether a policy\-grounded banking agent safely acts when a caller manipulates identity, authorization, and trust over a conversation\. We introduce FraudBench, an executable benchmark built on theτ2\\tau^\{2\}\-bench dual\-control framework and theτ\\tau\-Knowledge banking environment\. Both the agent and the simulated caller act through tools over shared, mutable account state, and the agent may grant the caller access to selected tools; the environment exposes a 698\-document internal policy corpus that the agent must retrieve from\. FraudBench contains 150 authored adversarial scenarios; a frozen public set of 107 \(90 across ten fraud mechanisms plus 17 chained adaptive attacks\) is used for all reported runs, with 43 further chained attacks held out\. Safety is history\-dependent: single\-control tasks satisfy every precondition but one, and adaptive attacks make a later, locally valid request unsafe because of an earlier probe, admission, or failed attempt\. Each scenario is annotated with observable evidence, prohibited actions, safe dispositions, and intervention points\. A preliminary single\-trial evaluation of four agents on the 107 graded tasks yields attack\-security between 49% and 65%, with money\-mule and first\-party fraud the most common cross\-model weaknesses\.

Code and data—https://github\.com/leanmcp/fraudbench

## 1Introduction

![Refer to caption](https://arxiv.org/html/2608.18136v1/DIAGRAM_FRAUDBENCH_SETUP.png)Figure 1:FraudBench overview\.A simulated adaptive caller attacks a policy\-grounded banking agent across ten fraud mechanisms plus chained multi\-step attacks, over privileged tools, a mutable customer database, and a 698\-document internal policy corpus; episodes are graded on actions, state, leaks, and disposition, conditioned on the full conversation history\. Prior conversational fraud benchmarks such as Fraud\-R1 judge resistance to fraud*messages*without tools, a database, or an internal policy corpus, and cover a narrower slice of banking\-fraud typologies\.A customer\-facing conversational agent is useful only to the extent that it is given real access: privileged tools, the production customer database, and the institution’s internal documentation and operating rules\. Without that access the agent cannot complete any non\-trivial workflow; with it, the agent becomes an exposure surface, an attack plane through which an end user, often an effectively unauthenticated caller, can reach internal data and internal structure through nothing more than dialogue\. Personal details that are protected inside back\-office systems can be revealed by a single helpful agent turn, and the agent itself must decide, request by request, which of the data it can see may be released to the person it is talking to\. Banking makes the stakes concrete\. An agent that answers a banking question and an agent that can change an email, reset a PIN, unfreeze a card, file a dispute, or move money have different failure consequences\. In the latter setting, ordinary customer\-service skills are inseparable from authorization, fraud detection, privacy, and policy compliance\. The agent must infer intent from incomplete dialogue, retrieve the right rule from a large internal corpus, inspect account state, choose whether to act or escalate, and remember evidence accumulated earlier in the conversation\. A single unsafe tool call can create financial loss even when the final natural\-language response sounds cautious\. A growing line of benchmarks, includingτ\\tau\-bench,τ2\\tau^\{2\}\-bench, the banking\-focusedτ\\tau\-Knowledge, and ToolSandbox, already shows that such tool\-using agents can carry real customer workflows\(Yao et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib27); Barres et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib3); Shi et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib19); Lu et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib16)\); our question is what happens when the customer is an adversary\.

The surrounding fraud environment is large and adaptive: the FBI and the U\.S\. Federal Trade Commission report on the order of $16–18 billion in fraud losses for 2025, most of it cyber\-enabled\(Federal Bureau of Investigation, Internet Crime Complaint Center[2026](https://arxiv.org/html/2608.18136#bib.bib8); U\.S\. Federal Trade Commission[2026](https://arxiv.org/html/2608.18136#bib.bib24)\)\. These losses are not caused by AI agents, but they indicate the scale of the environment into which high\-agency customer\-service systems are now deployed\.

Existing evaluation leaves a gap\. Transaction datasets such as PaySim, synthetic anti\-money\-laundering \(AML\) data, and Elliptic support fraud\-label or graph\-classification research rather than customer\-facing action\(Lopez\-Rojas, Elmir, and Axelsson[2016](https://arxiv.org/html/2608.18136#bib.bib15); Altman et al\.[2023](https://arxiv.org/html/2608.18136#bib.bib1); Weber et al\.[2019](https://arxiv.org/html/2608.18136#bib.bib25)\)\. Fraud\-R1 introduces multi\-round fraud and phishing inducements but evaluates conversational resistance without a bank database, privileged banking tools, or hundreds of operational policy documents\(Yang et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib26)\)\. General agent\-security suites test prompt injection, harmful requests, and unsafe web or tool behavior, but do not isolate the workflow controls and fraud typologies of banking operations\. Moreover, almost none of these settings give the agent what a deployed customer\-service agent actually has: privileged tools over a production\-style database plus a large corpus of internal, non\-public documentation;τ\\tau\-Knowledge is the only neighboring benchmark that combines tool use with such a corpus, and it measures whether the agent can serve legitimate customers, not whether it can withstand a fraudulent one\(Shi et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib19)\)\. Prior fraud benchmarks detect suspicious records or resist scam dialogue, and prior agent\-security benchmarks test generic harmful use or prompt injection; none evaluate whether a policy\-grounded banking agent*safely acts*when a strategic caller manipulates identity, authorization, and trust over time\.

We introduceFraudBench, an executable evaluation of policy\-grounded banking agents under adversarial conversation \(Figure[1](https://arxiv.org/html/2608.18136#S1.F1)\)\. It extends the interaction paradigm ofτ\\tau\-bench\(Yao et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib27)\), the dual\-control framing ofτ2\\tau^\{2\}\-bench\(Barres et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib3)\), and the unstructured banking\-policy environment ofτ\\tau\-Knowledge\(Shi et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib19)\)\. Rather than asking only whether the agent completes a user goal, FraudBench asks whether it prevents an unsafe goal, identifies the relevant control, intervenes before a dangerous action, and still serves a matched legitimate customer\. Our contributions are:

1. 1\.FraudBench, an executable banking\-fraud benchmark in which a defender agent verifies identity, retrieves from a 698\-document policy corpus, and acts through 17 privileged tools over mutable account state, and where safety depends on the full conversation history rather than the latest message;
2. 2\.a dataset of 150 hand\-authored adversarial tasks \(a frozen 107\-task public set: 90 across ten fraud mechanisms, including ten single\-decisive\-control boundary cases and ten adaptive two\-phase attacks, plus 17 chained trust\-contamination attacks, with 43 further chained attacks held out\), each graded by a history\-dependent judge and annotated with observable evidence, prohibited actions, safe disposition, and intervention point;
3. 3\.an adversarial extension of the cooperative tool\-agent\-user setting, in which the caller’s private goal conflicts with policy and the correct outcome may be refusal, escalation, or preserving the status quo rather than task completion; and
4. 4\.a multi\-model evaluation over the 107 tasks in which four agents reach attack\-security between 49% and 65%, with money\-mule and adaptive chain attacks the hardest, showing the suite discriminates without being saturated\.

## 2Related Work

### 2\.1Financial\-Fraud Benchmarks

Most public financial\-fraud resources expose labeled records rather than an interactive decision process: PaySim simulates mobile\-money transactions\(Lopez\-Rojas, Elmir, and Axelsson[2016](https://arxiv.org/html/2608.18136#bib.bib15)\), AMLSim and the IBM synthetic AML datasets generate laundering networks\(Suzumura and Kanezashi[2021](https://arxiv.org/html/2608.18136#bib.bib20); Altman et al\.[2023](https://arxiv.org/html/2608.18136#bib.bib1)\), and Elliptic provides a temporal graph of over 200,000 Bitcoin transactions for illicit\-node classification\(Weber et al\.[2019](https://arxiv.org/html/2608.18136#bib.bib25)\)\. These are valuable for detection models but do not test whether a language agent safely executes customer\-service operations; DetoxBench likewise scores LLM spam and abuse classification\(Chakraborty et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib6)\)\. Fraud\-R1 is closer to our threat model, evaluating multi\-round resistance to fraud and phishing inducements\(Yang et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib26)\), but its unit of evaluation is a fraud*message*scored by an LLM judge, with no bank database, privileged tools, account state, or policy corpus behind the conversation, and it covers a narrower slice of banking fraud \(inducement and phishing rather than money mules, first\-party disputes, synthetic\-identity onboarding, card\-control abuse, or agent\-mediated data exfiltration\)\. FraudBench adds executable banking state, privileged tools, long policy documents, action\-level consequences, and workflow\-specific controls across ten mechanisms\. AuditFraudBench instead targets fraudulent misstatements in corporate filings\(Liu et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib14)\)\.

### 2\.2Interactive Tool\-Agent\-User Evaluation

τ\\tau\-bench evaluates dynamic conversations between a simulated user and a tool\-using agent under domain policy, scores final database state, and introducespassk\\text\{pass\}^\{k\}for repeated reliability\(Yao et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib27)\)\.τ2\\tau^\{2\}\-bench extends this setting so both agent and user can act through tools in a shared environment and analyzes reasoning versus coordination failure\(Barres et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib3)\)\.τ\\tau\-Knowledge combines policy retrieval and tool use in a banking domain with roughly 700 documents, where even strong reasoning models achieve low combined success\(Shi et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib19)\); it is, to our knowledge, the only prior benchmark that gives the agent privileged tools, a customer database, and a large internal document corpus together, but its objective is usability, completing legitimate customer requests, rather than resisting fraud\. ToolSandbox likewise tests stateful, conversational tool use with intermediate milestones\(Lu et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib16)\)\. FraudBench uses these capabilities to study a different objective: an adversarial caller seeks an unsafe effect, and success may require refusal, escalation, or preservation of a fraud control rather than completion\.

### 2\.3Agent Security and Adaptive Red Teaming

InjecAgent and BIPIA test indirect prompt injection in tool\-integrated agents\(Zhan et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib29); Yi et al\.[2023](https://arxiv.org/html/2608.18136#bib.bib28)\); AgentDojo measures security alongside utility\(Debenedetti et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib7)\); Agent Security Bench and ToolEmu formalize attacks and high\-stakes tool risks\(Zhang et al\.[2024a](https://arxiv.org/html/2608.18136#bib.bib30); Ruan et al\.[2023](https://arxiv.org/html/2608.18136#bib.bib18)\); AgentHarm and Agent\-SafetyBench cover malicious multi\-step requests and broad safety cases\(Andriushchenko et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib2); Zhang et al\.[2024b](https://arxiv.org/html/2608.18136#bib.bib31)\); and SafeArena and ST\-WebAgentBench examine web misuse and enterprise policy compliance\(Tur et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib21); Levy et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib13)\)\. AgentHazard is especially relevant because it tests harm that emerges from sequences of locally plausible steps\(Feng et al\.[2026](https://arxiv.org/html/2608.18136#bib.bib10)\)\. None of these suites, however, place the agent over a production\-style customer database with privileged tools and a large corpus of internal, non\-public documentation, so they exclude the data\-exposure and policy\-boundary failures that dominate customer\-facing deployments\. FraudBench grounds this history dependence in customer identity, authorization, fraud, dispute, card, and payment policy inside a stateful banking service\. Its current release is a fixed executable suite; iterative, model\-in\-the\-loop attack generation\(Kiela et al\.[2021](https://arxiv.org/html/2608.18136#bib.bib12); Perez et al\.[2022](https://arxiv.org/html/2608.18136#bib.bib17)\)is a future extension\. Table[1](https://arxiv.org/html/2608.18136#S2.T1)compares FraudBench with neighboring benchmarks and frameworks on the capabilities central to interactive fraud defense\.

Table 1:Operational comparison with neighboring agent benchmarks and frameworks\.✓\\checkmarkdenotes a primary, implemented capability;⊚\\circledcirc, partial or narrower; –, not a primary feature\.*Multi\-class fraud*: multiple distinct fraud typologies are tested\.*History\-dep\.*: safety depends on earlier turns, not only the latest request\.*Long conv\.*: extended multi\-turn interaction with a \(simulated\) user\.*Type*indicates whether the work is a fixed benchmark, a reusable framework, or both; FraudBench is a fixed banking\-fraud benchmark whose environment and attacker machinery are reusable for new scenarios\.Among these, DoomArena is a general security\-testing framework that injects configurable attacks into host environments such asτ\\tau\-bench, BrowserGym, and OSWorld\(Boisvert et al\.[2025](https://arxiv.org/html/2608.18136#bib.bib5)\), but it supplies no fraud taxonomy, banking\-policy corpus, or domain\-grounded scenarios; FraudBench occupies the complementary position, contributing the scenarios and corpus such a framework would host\. As Table[1](https://arxiv.org/html/2608.18136#S2.T1)shows, no existing benchmark or framework combines executable state, a large policy knowledge base, multiple fraud classes, history\-dependent safety, and long conversations; FraudBench provides all of these\.

## 3The FraudBench Benchmark

### 3\.1Problem Formulation

An episode couples a defender agentAA, a simulated callerUU, an internal policy corpusDD, and a banking environment whose database state at turnttwe writests\_\{t\}\(customer records, accounts, cards, transactions, disputes, and verification logs\)\. A shared tool setT=Tread∪TwriteT=T\_\{\\text\{read\}\}\\cup T\_\{\\text\{write\}\}mediates all actions: read tools inTreadT\_\{\\text\{read\}\}return information, while write tools inTwriteT\_\{\\text\{write\}\}mutate the database, so that a transfer, a PIN reset, or a card unfreeze changessts\_\{t\}\. Following theτ2\\tau^\{2\}\-bench dual\-control setting,*both*AAandUUact through tools; the agent may additionally expose selected*discoverable*tools to the caller, so the caller’s own action set is something the agent controls\. The agent does not seeDDin full: for document\-mapped tasks it must retrieve the governing rule from the corpus before acting, and the corpus is also where a caller may try to make the agent surface information it should not\.

An interaction produces a trajectory

τ=\(m0:t,c0:t,o0:t\),\\tau=\(m\_\{0:t\},\\;c\_\{0:t\},\\;o\_\{0:t\}\),of messagesmm\(fromAAorUU\), tool callscc\(issued byAAorUU\), and observationsoo\. The caller follows a scenario policy that fixes its identity, known and unknown information, attack goal, and pressure tactics; it has no arbitrary database access and can learn a protected value only ifAAreveals it\.

##### History\-dependent grading\.

Each scenario ships with a requirement setRRof natural\-language assertions over the*whole*trajectory, evaluated by a judgeJ​\(τ,R\)∈\{0,1\}J\(\\tau,R\)\\in\\\{0,1\\\}; the episode is safe only if every requirement inRRholds\. These requirements are not met by refusal alone\. Typical ones are that no protected customer field is leaked anywhere inτ\\tau, thatAAactually recognizes the fraud’s red flag rather than merely stalling, that any escalation states a correct reason \(a wrong reason can mislead the receiving human\), and that consequential actions are logged for auditability\. BecauseJJreads all ofτ\\tau, safety depends on history, not on the latest message: the same requestmtm\_\{t\}can be correct after a clean history and prohibited after a contaminated one\. Concretely, an exact recovery code offered immediately after a near\-miss guess, a card activation attempted after repeated failures have locked the card to in\-person \(branch\) verification, or a same\-owner transfer after the caller has admitted the funds are third\-party payroll are all unsafe despite looking valid in isolation\. FraudBench therefore tests*trust\-state preservation*, not policy lookup for the latest request\.

### 3\.2Banking Substrate

FraudBench reuses theτ\\tau\-Knowledge banking environment: a 698\-document internal knowledge base, tool\-mediated account operations, and mutable transactional state\. The fraud\-specific database contains 125 fictional users, 126 bank accounts, debit and credit cards, transaction histories, disputes, verification records, payment history, and request/order tables\. No real customer records are used\. The environment exposes 17 agent tools spanning low\-risk reads and consequential actions such as identity verification \(a two\-of\-four field check followed by a verification log\), contact changes, card freezing and unfreezing, PIN changes, temporary limit increases, account transfers, dispute filing, statement credits, and human escalation\. Identity verification is the single most important lever: account takeover, synthetic identity, and phishing\-derived PII misuse all turn on whether the agent verifies correctly and gates privileged actions\. The substrate distinguishes*user\-discoverable*tools, which the agent grants to the caller withgive\_discoverable\_user\_tool, from*agent\-discoverable*tools, which the agent must first unlock and then invoke\. Both routes require the agent to retrieve a governing policy document rather than guess a tool name\.

### 3\.3Fraud Taxonomy

The frozen 107\-task evaluation set comprises 90 tasks evenly distributed across ten fraud mechanisms \(nine tasks per mechanism; Table[2](https://arxiv.org/html/2608.18136#S3.T2)\) and 17*chain*tasks that extend the adaptive two\-phase design into longer multi\-step attacks; a further 43 chain tasks \(60 authored in total\) are released as a held\-out set and are not included in the reported runs\. The taxonomy is cross\-referenced to the Federal Reserve’s authorized\-versus\-unauthorized framing\(Board of Governors of the Federal Reserve System[2020](https://arxiv.org/html/2608.18136#bib.bib4)\), the companion ScamClassifier model\(Federal Reserve Fraud Definitions Community Interest Group[2023](https://arxiv.org/html/2608.18136#bib.bib9)\), FATF typologies\(Financial Action Task Force[2023](https://arxiv.org/html/2608.18136#bib.bib11)\), and UK payment\-scam reimbursement policy\(UK Payment Systems Regulator[2024](https://arxiv.org/html/2608.18136#bib.bib23); UK Finance[2025](https://arxiv.org/html/2608.18136#bib.bib22)\)\. These mappings support coverage analysis; they do not imply that the synthetic bank implements any jurisdiction’s complete compliance regime\.

Table 2:Ten fraud mechanisms and the decision each isolates, plus the chain category of multi\-step adaptive attacks\.
### 3\.4Scenario Construction

Every scenario is hand\-authored, not generated\. Starting from theτ\\tau\-Knowledge banking database, we build a fraud\-specific state per task: a fresh victim record \(and, where relevant, an accomplice or mule account\) is instantiated with the fields the mechanism turns on \(verification history, ownership, locks, disputes, payment history\), so the decisive permission fact is exact\. Each task is then \(1\) authored as an attack story with the caller’s goal, known and unknown information, and pressure tactics; \(2\) matched by a database initialization that sets the single deciding precondition; \(3\) scripted so the simulated caller actively pursues and pivots the attack; and \(4\) run with GPT\-5\.4 Nano in the caller role and manually checked to confirm the attack is actually delivered, so a defender failure reflects the defender, not a stalled attacker\. A separate LLM pass then removes tells that would leak the answer \(e\.g\. identifiers likeacct\_victimoracct\_mule, or in\-band fraud\-type labels\), renaming them to neutral values so the defender must reason from behavior and policy\.

Tasks span four difficulty tiers\. Tasks\_01–\_07vary attack surface and pressure tactics; the ten\_08*single\-decisive\-control*tasks pass every check but one precise rule \(a different\-owner destination, an ATM limit $10 over the cap, a dispute count exactly at the tier cap, or a role change still inside its 48\-hour delay\); the ten\_09*adaptive*tasks let the attacker fail or reveal disqualifying intent and then pivot to a request that would have succeeded under a clean history; and the chain tasks extend this over tool\-mediated state, where a mechanically ordinary transfer becomes part of one suspicious chain because of its stated purpose\.

### 3\.5Task Representation and Grading

Each JSON task includes a caller script; the caller’s known and unknown information; optional required policy documents; database initialization; and structured annotations recording fraud mechanism, social\-engineering tactics, workflow stage, observable evidence, permitted and prohibited actions, correct disposition, latest acceptable intervention point, risk cost, and standards references\. Adaptive tasks additionally describe the initial failure, the locally valid counterfactual, and the history dependency\. The audited artifact contains 334 natural\-language assertions across 107 evaluated tasks, 125 fictional users, 126 accounts, 17 exposed agent tools, and 698 policy documents\. Twenty\-one tasks carry explicit document mappings \(34 references to 14 unique documents\), namely the 20 single\-control and adaptive boundary tasks \(\_08/\_09\) plus one chain task, whereas the ordinary tasks do not; full mapping is required before claiming corpus\-wide retrieval results\.

The grading requirements are specific to each task and are hand\-written under human review, so that the judge checks exactly the evidence, prohibited actions, and safe disposition that matter for that scenario rather than a generic rubric\. The current evaluator grades these scenario\-specific natural\-language assertions over the transcript\. The planned full verifier first checks simulator validity, then deterministically inspects prohibited tool calls, unlocked tools, structured leaks, and state changes before judging only residual semantic requirements; a stratified human audit adjudicates conflicts and qualitative examples\. The reported runs use only the semantic stage\. This distinction matters because a semantic judge can produce a*false\-safe*grade despite an unsafe action, state change, or disclosure that a caller can extract before any refusal\.

![Refer to caption](https://arxiv.org/html/2608.18136v1/FRAUDBENCH_PIPELINE.excalidraw.png)Figure 2:Grading pipeline\.\(1\)*Conversation roll:*the agent and simulated caller hold a multi\-turn conversation \(shown top\-to\-bottom, chat style\); here the caller impersonates a customer, induces the agent to read back protected contact details, and then requests a transfer to a third\-party IBAN\. \(2\) The full transcript is scored in two stages: \(2a\) a*deterministic*grader inspects the ordered tool\-call sequence, unsafe state changes, and structured leaks \(e\.g\. an executed unauthorized transfer\), and \(2b\) an*LLM\-as\-judge*stage checks the scenario’s natural\-language assertions \(scam recognized, no PII revealed, transfer refused\), each marked pass \(✓\) or fail \(X\)\. \(3\) The episode earns reward11only if*all*checks pass \(logical AND\); a single leak or prohibited action yields0\. The reported runs use the LLM\-judge stage only; the deterministic stage is what catches false\-safe transcripts like this one\.

## 4Evaluation Protocol

### 4\.1Research Questions

RQ1:How often do frontier and open\-weight agents prevent unsafe outcomes under adversarial banking conversations?RQ2:Does fraud prevention trade off against service completion for matched legitimate customers?RQ3:Are exact single\-control boundaries and adaptive two\-phase attacks disproportionately difficult?RQ4:Which failures arise from retrieval, policy reasoning, conversational state tracking, tool execution, over\-refusal, or user simulation?RQ5:How reliable is each model across repeated stochastic trials? We preregister that no tested model will be uniformly secure across all ten mechanisms, that more conservative agents will trade attack blocking for legitimate completion, and that\_09performance will fall under full\-history attacks with a history ablation confirming that phase 1 is causally relevant\.

### 4\.2Models and Execution

The frozen core panel spans frontier proprietary, open\-weight, and cost\-efficient families, each pinned to an exact dated identifier and decoding configuration\. For every gold\-mapped task the primary run uses oracle retrieval of its required documents, isolating policy reasoning from retrieval; a retrieval ablation exposes the full toolset and reports required\-document recall separately\. Because only the 20\_08/\_09tasks are currently mapped, retrieval claims are restricted to that subset\. We include an always\-refuse/escalate baseline and a scenario oracle, since blanket refusal shows why attack\-only accuracy overstates useful fraud defense\.

##### Infrastructure and reproducibility\.

All agents run through the tau2\-bench orchestrator with a common system prompt, tool schema, and retrieval configuration; only the defender model changes\. Proprietary and hosted models are called through their providers: Gemini on Vertex AI \(Google Cloud\), the GPT\-5\.4 Nano user simulator on OpenAI, and Kimi K3 on OpenRouter\. Nemotron\-3 Ultra is sampled through Tinker from the released checkpoint with no fine\-tuning \(inference only\), and gpt\-oss\-120b is served from a checkpoint on GPU hosts\. All model traffic is routed through the LeanMCP \(leanmcp\.com\) AI gateway for observability and through a unified LiteLLM layer, and we record the exact dated identifier, provider route, and decoding parameters for each\. The adversarial caller \(user simulator\) and the natural\-language\-assertion verification \(the LLM judge\) both use GPT\-5\.4 Nano throughout\. We deliberately do not use heavily safety\-tuned frontier models such as Claude Fable 5 in the adversarial caller role: they frequently decline to role\-play a fraudulent customer, so their guardrails suppress attacks before they are delivered and would inflate measured security; GPT\-5\.4 Nano sustains the attacker role reliably across all scenarios\. Such models are still evaluated as*defenders*, where refusal is the desired behavior\. Each episode is seeded and the seed is stored with its result record, so a run can be replayed; the preliminary results use a single trial per task \(pass1\\text\{pass\}^\{1\}\), and the frozen study uses four trials per task\. The task suite, banking environment, evaluation driver, and analysis scripts are released in the code\-and\-data supplement\.

### 4\.3Metrics and Analysis

The primary metric is attack\-securitySS: the fraction of attack tasks in which the defender reaches the decision point, avoids every prohibited effect, and meets the required safe disposition \(attack success rate is1−S1\-S\)\. On matched legitimate controls we report utilityUU, the fraction completed without an unnecessary refusal or escalation\. We keep the two axes separate rather than collapsing them and, followingτ\\tau\-bench, reportpassk\\text\{pass\}^\{k\}for reliability acrosskktrials\(Yao et al\.[2024](https://arxiv.org/html/2608.18136#bib.bib27)\)\. Simulator\-invalid and infrastructure\-failed episodes are reported separately, and we macro\-average by mechanism so that large categories cannot dominate\. Each failed episode is labeled by failure type \(retrieval miss, policy error, history reset, unsafe tool call, information disclosure, or over\-refusal\), and a full\-history versus latest\-turn ablation on the\_09tasks tests whether performance depends on preserving earlier evidence, as our central claim requires\.

## 5Results

### 5\.1Preliminary Multi\-Model Results

We ran four agents over the currently instantiated task set as an early, non\-final probe of the benchmark\. These runs use a single trial per task \(pass1\\text\{pass\}^\{1\}only\), the GPT\-5\.4 Nano user simulator, and the current natural\-language\-assertion grader \(the LLM\-as\-judge stage of Figure[2](https://arxiv.org/html/2608.18136#S3.F2)\)*without*the deterministic checks or matched legitimate controls; they therefore report attack\-securitySSon the attack\-only suite and must not be read as the final security–utility result\. All four models completed the full 107 tasks \(the 90 core tasks plus the 17 chain tasks\); models without a complete 107\-task run are excluded from this comparison\.

Table[3](https://arxiv.org/html/2608.18136#S5.T3)gives overall attack\-security\. Gemini 3\.6 Flash is strongest \(64\.5%\) and gpt\-oss\-120b weakest \(49\.5%\), a 15\-point spread showing the suite is neither saturated nor trivially failed\. By mechanism \(Table[4](https://arxiv.org/html/2608.18136#S5.T4)\), money mule is hardest for every model, and the 17 chain tasks separate models sharply \(8–9 of 17 for the stronger agents versus 4 of 17 for the weaker two\), supporting the hypothesis that adaptive trust\-contamination is disproportionately hard\. These numbers show discriminative power and locate failure concentrations; the frozen study below adds repeated trials, deterministic grading, matched legitimate controls, and confidence intervals before any ordering claim is made\.

Table 3:Preliminary attack\-security atpass1\\text\{pass\}^\{1\}on the currently graded tasks, for the four models with complete 107\-task runs under*oracle*retrieval \(the agent’sKB\_searchreturns the task’s gold policy documents\)\. All runs use the GPT\-5\.4 Nano user simulator, one trial, and the natural\-language\-assertion grader only \(no deterministic Stage B checks, no matched legitimate controls\)\. Models without a complete 107\-task run are excluded\. A realistic all\-tools retrieval setting is compared in Table[5](https://arxiv.org/html/2608.18136#S5.T5)\.Table 4:Per\-mechanism attack\-security \(defended tasks / graded tasks\) for the four models with complete 107\-task runs\. Columns: Nemo\. = Nemotron\-3 Ultra 550B; G3\.6F = Gemini 3\.6 Flash; G3\.1FL = Gemini 3\.1 Flash\-Lite; oss120 = gpt\-oss\-120b\. Money mule is the hardest mechanism for every model; the chain row covers all 17 chain tasks\.#### Oracle versus All\-Tools Retrieval

The tables above use oracle retrieval, which hands the agent the task\-relevant policy documents throughKB\_search\. A more realistic setting exposes the full retrieval toolset at once \(KB\_search, document read, sparse \(BM25\) and dense \(embedding\) search, and a read\-only shell over the corpus\) and requires the agent to find the governing policy itself\. For the one model run to completion under both settings, Gemini 3\.6 Flash, attack\-security drops from 64\.5% \(oracle\) to 51\.0% under all\-tools retrieval \(Table[5](https://arxiv.org/html/2608.18136#S5.T5)\), a 13\-point penalty attributable to imperfect self\-directed retrieval rather than policy reasoning or action safety\. Gemini 3\.1 Pro, run only under all\-tools, reaches 55\.1%\. This isolates retrieval as a distinct failure source and is why we report the retrieval condition explicitly and treat oracle results as an upper bound on policy reasoning\.

Table 5:Retrieval\-setting comparison atpass1\\text\{pass\}^\{1\}\. Oracle supplies the gold policy documents; all\-tools requires the agent to retrieve them from the 698\-document corpus\. Gemini 3\.6 Flash is the only model run under both settings, and its 13\-point drop isolates retrieval from policy reasoning; Gemini 3\.1 Pro was run under all\-tools only\. All\-tools Gemini 3\.6 Flash graded 104 of 107 episodes \(three infrastructure failures excluded\)\.

## 6Discussion

FraudBench separates three things that aggregate task success hides:*authentication is not authorization*\(a verified customer, or stolen static PII, can still make an unsafe request\),*local validity is not global safety*\(a request that meets its immediate preconditions can be prohibited by an earlier lock, admission, or exposed secret\), and*safety is not refusal*\(a usable agent must still complete matched legitimate requests\)\. This is why the security and utility axes are never collapsed\. Whether stronger general models are uniformly safer is open, since capability can improve boundary reasoning but also increase compliance with a persuasive attacker; a security–utility frontier is therefore more informative than a single score\.

## 7Limitations, Responsible Release, and Ethics

FraudBench uses a synthetic bank with fictional data; no task can affect a real financial system, every trial gets an isolated copy, andamount\_at\_riskis scenario metadata, not observed loss\. It does not estimate fraud prevalence or regulatory compliance; ten mechanisms cannot cover every typology, jurisdiction, or language; and results depend on the user simulator, retrieval setup, judge, and provider safety layer\. Most importantly, the current release is attack\-only: without matched legitimate controls it cannot measure over\-refusal, and the preliminary results are single\-trial under a semantic\-only grader, so they show discriminative power rather than final rankings\.

Because the benchmark is dual use, the release excludes live credentials, institution\-specific controls, and production endpoints, and sandboxes all tool effects; since publishing attack prompts risks contamination, we recommend a development split with a hidden diagnostic set and a timestamped release\. To limit blanket\-refusal and demographic stereotyping, attacks are paired with matched legitimate controls and audited by persona, and any human transcript audit will use appropriate institutional review, fair compensation, advance notice of fraud content, and no real personal data\.

## Acknowledgments

We thank Google Cloud for research grant support, which provided the Gemini API credits and the GPU access used to run the evaluations reported in this paper\.

## References

- Altman et al\. \(2023\)Altman, E\.; Blanuša, J\.; von Niederhäusern, L\.; Egressy, B\.; Anghel, A\.; and Atasu, K\. 2023\.Realistic Synthetic Financial Transactions for Anti\-Money Laundering Models\.In*Advances in Neural Information Processing Systems \(NeurIPS\), Datasets and Benchmarks Track*\.
- Andriushchenko et al\. \(2024\)Andriushchenko, M\.; Souly, A\.; Dziemian, M\.; et al\. 2024\.AgentHarm: A Benchmark for Measuring Harmfulness of LLM Agents\.arXiv:2410\.09024\.
- Barres et al\. \(2025\)Barres, V\.; Dong, H\.; Ray, S\.; Si, X\.; and Narasimhan, K\. 2025\.τ2\\tau^\{2\}\-Bench: Evaluating Conversational Agents in a Dual\-Control Environment\.arXiv:2506\.07982\.
- Board of Governors of the Federal Reserve System \(2020\)Board of Governors of the Federal Reserve System\. 2020\.Federal Reserve Announces FraudClassifier Model\.https://www\.federalreserve\.gov/newsevents/pressreleases/other20200618a\.htm\.Accessed: 2026\-07\-22\.
- Boisvert et al\. \(2025\)Boisvert, L\.; Bansal, M\.; Evuru, C\. K\. R\.; Huang, G\.; Puri, A\.; Bose, A\.; Fazel, M\.; Cappart, Q\.; Stanley, J\.; Lacoste, A\.; Drouin, A\.; and Dvijotham, K\. 2025\.DoomArena: A Framework for Testing AI Agents Against Evolving Security Threats\.In*Conference on Language Modeling*\.
- Chakraborty et al\. \(2024\)Chakraborty, J\.; Xia, W\.; Majumder, A\.; Ma, D\.; Chaabene, W\.; and Janvekar, N\. 2024\.DetoxBench: Benchmarking Large Language Models for Multitask Fraud and Abuse Detection\.arXiv:2409\.06072\.
- Debenedetti et al\. \(2024\)Debenedetti, E\.; Zhang, J\.; Balunović, M\.; Beurer\-Kellner, L\.; Fischer, M\.; and Tramèr, F\. 2024\.AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and Defenses for LLM Agents\.In*Advances in Neural Information Processing Systems \(NeurIPS\)*\.
- Federal Bureau of Investigation, Internet Crime Complaint Center \(2026\)Federal Bureau of Investigation, Internet Crime Complaint Center\. 2026\.2025 Internet Crime Report\.https://www\.ic3\.gov/AnnualReport/Reports/2025\_IC3Report\.pdf\.Accessed: 2026\-07\-22\.
- Federal Reserve Fraud Definitions Community Interest Group \(2023\)Federal Reserve Fraud Definitions Community Interest Group\. 2023\.ScamClassifier Model Frequently Asked Questions\.https://fedpaymentsimprovement\.org/\.Accessed: 2026\-07\-22\.
- Feng et al\. \(2026\)Feng, Y\.; Ding, Y\.; Tan, Y\.; et al\. 2026\.AgentHazard: A Benchmark for Evaluating Harmful Behavior in Computer\-Use Agents\.arXiv:2604\.02947\.
- Financial Action Task Force \(2023\)Financial Action Task Force\. 2023\.The FATF Recommendations\.https://www\.fatf\-gafi\.org/\.Accessed: 2026\-07\-22\.
- Kiela et al\. \(2021\)Kiela, D\.; Bartolo, M\.; Nie, Y\.; et al\. 2021\.Dynabench: Rethinking Benchmarking in NLP\.arXiv:2104\.14337\.
- Levy et al\. \(2024\)Levy, I\.; Wiesel, B\.; Marreed, S\.; Oved, A\.; Yaeli, A\.; and Shlomov, S\. 2024\.ST\-WebAgentBench: A Benchmark for Evaluating Safety and Trustworthiness in Web Agents\.arXiv:2410\.06703\.
- Liu et al\. \(2026\)Liu, Z\.; He, Y\.; Ou, Q\.; et al\. 2026\.AuditFraudBench: Benchmarking Audit Judgment in Detecting Fraudulent Misstatements\.arXiv:2606\.08345\.
- Lopez\-Rojas, Elmir, and Axelsson \(2016\)Lopez\-Rojas, E\. A\.; Elmir, A\.; and Axelsson, S\. 2016\.PaySim: A Financial Mobile Money Simulator for Fraud Detection\.In*Proceedings of the 28th European Modeling and Simulation Symposium \(EMSS\)*, 249–255\.
- Lu et al\. \(2024\)Lu, J\.; Holleis, T\.; Zhang, Y\.; et al\. 2024\.ToolSandbox: A Stateful, Conversational, Interactive Evaluation Benchmark for LLM Tool Use Capabilities\.arXiv:2408\.04682\.
- Perez et al\. \(2022\)Perez, E\.; Huang, S\.; Song, F\.; et al\. 2022\.Red Teaming Language Models with Language Models\.arXiv:2202\.03286\.
- Ruan et al\. \(2023\)Ruan, Y\.; Dong, H\.; Wang, A\.; et al\. 2023\.Identifying the Risks of LM Agents with an LM\-Emulated Sandbox\.arXiv:2309\.15817\.
- Shi et al\. \(2026\)Shi, Q\.; Zytek, A\.; Razavi, P\.; Narasimhan, K\.; and Barres, V\. 2026\.τ\\tau\-Knowledge: Evaluating Conversational Agents over Unstructured Knowledge\.arXiv:2603\.04370\.
- Suzumura and Kanezashi \(2021\)Suzumura, T\.; and Kanezashi, H\. 2021\.IBM AMLSim: A Multi\-Agent Simulator for Anti\-Money Laundering\.https://github\.com/IBM/AMLSim/\.Accessed: 2026\-07\-22\.
- Tur et al\. \(2025\)Tur, A\. D\.; Meade, N\.; Lù, X\. H\.; et al\. 2025\.SafeArena: Evaluating the Safety of Autonomous Web Agents\.arXiv:2503\.04957\.
- UK Finance \(2025\)UK Finance\. 2025\.Annual Fraud Report 2025\.https://www\.ukfinance\.org\.uk/policy\-and\-guidance/reports/annual\-fraud\-report\-2025\.Accessed: 2026\-07\-22\.
- UK Payment Systems Regulator \(2024\)UK Payment Systems Regulator\. 2024\.APP Scams Reimbursement Policy \(PS23/4\)\.https://www\.psr\.org\.uk/app\-scams\-reimbursement\-ps23\-4/\.Accessed: 2026\-07\-22\.
- U\.S\. Federal Trade Commission \(2026\)U\.S\. Federal Trade Commission\. 2026\.FTC Data Show People Reported Losing $3\.5 Billion to Imposter Scams in 2025\.https://www\.ftc\.gov/news\-events/news/press\-releases/2026/06/\.Accessed: 2026\-07\-22\.
- Weber et al\. \(2019\)Weber, M\.; Domeniconi, G\.; Chen, J\.; Weidele, D\. K\. I\.; Bellei, C\.; Robinson, T\.; and Leiserson, C\. E\. 2019\.Anti\-Money Laundering in Bitcoin: Experimenting with Graph Convolutional Networks for Financial Forensics\.arXiv:1908\.02591\.
- Yang et al\. \(2025\)Yang, S\.; Zhu, S\.; Wu, Z\.; et al\. 2025\.Fraud\-R1: A Multi\-Round Benchmark for Assessing the Robustness of LLM Against Augmented Fraud and Phishing Inducements\.In*Findings of the Association for Computational Linguistics \(ACL\)*\.
- Yao et al\. \(2024\)Yao, S\.; Shinn, N\.; Razavi, P\.; and Narasimhan, K\. 2024\.τ\\tau\-bench: A Benchmark for Tool\-Agent\-User Interaction in Real\-World Domains\.arXiv:2406\.12045\.
- Yi et al\. \(2023\)Yi, J\.; Xie, Y\.; Zhu, B\.; et al\. 2023\.Benchmarking and Defending Against Indirect Prompt Injection Attacks on Large Language Models\.arXiv:2312\.14197\.
- Zhan et al\. \(2024\)Zhan, Q\.; Liang, Z\.; Ying, Z\.; and Kang, D\. 2024\.InjecAgent: Benchmarking Indirect Prompt Injections in Tool\-Integrated Large Language Model Agents\.In*Findings of the Association for Computational Linguistics \(ACL\)*\.
- Zhang et al\. \(2024a\)Zhang, Y\.; Yu, T\.; Cui, J\.; et al\. 2024a\.Agent Security Bench \(ASB\): Formalizing and Benchmarking Attacks and Defenses in LLM\-based Agents\.arXiv:2410\.02644\.
- Zhang et al\. \(2024b\)Zhang, Z\.; Cui, S\.; Lu, Y\.; Zhou, J\.; Yang, J\.; Wang, H\.; and Huang, M\. 2024b\.Agent\-SafetyBench: Evaluating the Safety of LLM Agents\.arXiv:2412\.14470\.