Fraud Scenario Library Governance

2. Summary

Fraud Scenario Library Governance requires that every organisation operating AI agents with financial capabilities maintains a structured, versioned, and continuously updated library of fraud scenarios specific to agent-mediated financial operations. The library codifies known attack patterns, emerging threat vectors, and organisation-specific fraud risks into testable scenarios that inform detection rules, agent behaviour constraints, tabletop exercises, and red-team simulations. Without a governed fraud scenario library, fraud detection operates against an implicit and incomplete threat model — the organisation defends against the attacks it happens to have encountered or imagined, rather than against a systematically catalogued and continuously expanded set of scenarios drawn from industry intelligence, regulatory guidance, and adversarial research.

3. Example

Scenario A — Agent-Mediated Invoice Duplication Fraud Undetected for 11 Months: An enterprise workflow agent processes accounts payable for a manufacturing company, handling approximately 2,400 invoices per month. A fraudster within a supplier organisation discovers that the agent validates invoices against purchase orders but does not detect near-duplicate invoices — invoices with the same amount and supplier but different invoice numbers, submitted 30-60 days apart. The fraudster submits 47 duplicate invoices over 11 months, each for amounts between £8,500 and £14,200, totalling £523,000. The agent processes and pays each duplicate because its fraud detection logic does not include an "invoice near-duplication" scenario. The fraud is discovered only when a manual quarterly review flags the supplier's total payments as 34% above contract value. Investigation reveals that the organisation's fraud detection rules were based on a static list of 12 fraud patterns defined at initial deployment. No fraud scenario library existed to systematically identify, catalogue, and update detection patterns. The "invoice near-duplication" pattern was documented in a financial fraud advisory published 8 months before the first fraudulent invoice, but no process existed to incorporate external fraud intelligence into the agent's detection logic.

What went wrong: The organisation had no governed fraud scenario library. Detection rules were static, defined at deployment, and never updated with emerging patterns. External fraud intelligence was not systematically ingested. The specific attack pattern — near-duplicate invoices with different invoice numbers — was a known fraud vector that was publicly documented but absent from the agent's detection logic. Consequence: £523,000 in fraudulent payments, 11 months of undetected fraud, supplier relationship termination, and £89,000 in forensic investigation costs.

Scenario B — Social Engineering of Customer-Facing Agent Exploiting Unmodelled Scenario: A customer-facing agent at an insurance company is authorised to process policy changes, including beneficiary updates and payout redirections. A fraudster contacts the agent, impersonating a policyholder, and requests a beneficiary change followed by an immediate claim payout to a new bank account. The agent's fraud detection includes scenarios for identity verification failure and for payout amounts exceeding policy limits, but it does not include a scenario for the combination of beneficiary change followed by immediate payout request — a classic "account takeover then cash-out" pattern. The agent processes the beneficiary change (passing identity verification with stolen credentials) and approves the £67,000 payout to the fraudster's account. The real policyholder discovers the fraud 3 weeks later. The insurer cannot recover the funds. The Financial Ombudsman Service investigation finds that the "beneficiary change plus immediate payout" pattern is documented in at least 4 industry fraud alerts from the previous 2 years, none of which had been incorporated into the agent's detection logic.

What went wrong: The agent's fraud detection operated against an ad-hoc list of scenarios that did not include multi-step combination patterns. No fraud scenario library existed to catalogue compound fraud patterns — scenarios where individual steps are each legitimate but the combination constitutes fraud. External industry fraud alerts were not systematically reviewed and incorporated. The specific pattern was well-documented in industry intelligence but absent from the agent's threat model. Consequence: £67,000 irrecoverable loss, regulatory complaint, Financial Ombudsman finding against the firm, and £23,000 in complaint handling and remediation costs.

Scenario C — Crypto Agent Vulnerable to Flash Loan Attack Pattern Not in Threat Model: A Crypto/Web3 agent managing a decentralised finance treasury is authorised to execute swaps, provide liquidity, and manage yield positions across 5 protocols. The agent's fraud detection includes scenarios for rug pulls (sudden liquidity removal), price manipulation (gradual price distortion), and phishing (malicious contract approvals). It does not include a scenario for flash loan attacks — transactions where an attacker borrows a large sum within a single block, uses it to manipulate a price oracle, and exploits the temporary price distortion to drain funds, all within a single atomic transaction. A flash loan attack against one of the 5 protocols causes the agent's price oracle to report a distorted price. The agent executes a swap based on the distorted price, losing $184,000 in a single transaction. The flash loan attack pattern has been documented in at least 23 post-mortem analyses of similar attacks over the preceding 18 months, and defensive strategies (multi-oracle verification, time-weighted average pricing, flash loan detection heuristics) are well-established in the industry. None of these were implemented because the pattern was not in the agent's fraud scenario library.

What went wrong: The fraud scenario library (to the extent one existed) was limited to traditional financial fraud patterns and did not include DeFi-specific attack vectors. Flash loan attacks — the most common and well-documented DeFi attack vector — were absent from the threat model. No process existed to systematically review DeFi security post-mortems and incorporate new attack patterns. The agent operated with a threat model that was 18 months out of date relative to the actual threat landscape. Consequence: $184,000 loss in a single transaction, protocol trust damage, and insurance claim complications due to the organisation's failure to implement known defensive measures.

4. Requirement Statement

Scope: This dimension applies to every AI agent that initiates, approves, processes, recommends, or facilitates financial transactions, including payments, invoicing, claims processing, treasury operations, trading, lending, insurance payouts, and digital asset operations. The scope extends to agents that do not directly process payments but whose outputs influence financial decisions — for example, a customer-facing agent whose recommendations lead to purchases, or an enterprise workflow agent whose approvals trigger downstream payments. The fraud scenario library is a structured knowledge base, not a detection system; it informs detection systems (governed by AG-025), simulation exercises (governed by AG-420 and AG-429), and agent behaviour constraints (governed by AG-001). This dimension governs the library itself — its structure, its update process, its coverage requirements, and its integration with detection and testing systems.

4.1. A conforming system MUST maintain a structured fraud scenario library containing documented fraud patterns, attack vectors, and threat scenarios relevant to the financial operations performed by or influenced by the organisation's AI agents.

4.2. A conforming system MUST structure each scenario in the library with at least the following fields: unique scenario identifier, scenario name, attack description (including step-by-step execution), preconditions required for the attack to succeed, detection indicators (observable signals during or after the attack), defensive measures (controls that prevent or mitigate the attack), applicable agent profiles, severity rating, source reference (industry alert, regulatory guidance, incident post-mortem, or internal discovery), and date added.

4.3. A conforming system MUST review and update the fraud scenario library at least quarterly, incorporating new scenarios from: industry fraud intelligence feeds, regulatory alerts and guidance, published incident post-mortems, internal incident reports, red-team and tabletop exercise findings (per AG-420 and AG-429), and adversarial research.

4.4. A conforming system MUST map every scenario in the library to at least one detection rule, agent behaviour constraint, or compensating control, with documented evidence that the mapping is implemented and operational — a scenario without a corresponding defensive measure is an acknowledged unmitigated risk that requires explicit risk acceptance.

4.5. A conforming system MUST include compound fraud scenarios — multi-step attack patterns where individual steps are each legitimate but the combination constitutes fraud — not only single-action fraud patterns.

4.6. A conforming system MUST include fraud scenarios specific to the technology stack and operational context of AI agents, including: prompt injection attacks designed to bypass financial controls, social engineering of customer-facing agents, manipulation of agent decision inputs (price feeds, identity verification data, document forgeries), and exploitation of agent autonomy boundaries.

4.7. A conforming system MUST version the fraud scenario library with immutable version identifiers and retain all prior versions, enabling historical analysis of which scenarios were known at the time of any given transaction or incident.

4.8. A conforming system MUST conduct an annual coverage assessment that evaluates the library against: the current threat landscape for the organisation's industry and operational profile, published fraud taxonomies from relevant authorities (e.g., financial crime authorities, cybersecurity agencies, blockchain security firms), and the organisation's own incident history.

4.9. A conforming system SHOULD implement automated ingestion of external fraud intelligence, parsing structured threat feeds into candidate library entries that are reviewed and approved by a qualified analyst before activation.

4.10. A conforming system SHOULD implement scenario simulation capability, allowing each library scenario to be executed as a controlled test against the agent's fraud detection systems to verify that the corresponding detection rules or constraints are effective.

4.11. A conforming system SHOULD maintain a scenario effectiveness register recording, for each scenario, whether the corresponding detection rule has ever triggered in production, the false positive rate, and the time-to-detection for confirmed incidents matching the scenario.

4.12. A conforming system MAY implement machine-learning-assisted scenario generation that analyses transaction patterns, anomaly detection outputs, and external threat intelligence to propose novel scenario candidates for human review and approval.

4.13. A conforming system MAY share anonymised scenario data with industry peers through recognised information-sharing frameworks (e.g., financial sector ISACs) to contribute to collective fraud defence.

5. Rationale

Financial fraud is adversarial. Attackers continuously evolve their methods to exploit new technologies, new processes, and new vulnerabilities. AI agents introduce a fundamentally new attack surface: they are automated, fast, consistent, and — critically — they follow deterministic rules that an attacker can study and circumvent. A human accounts payable clerk brings intuition, suspicion, and contextual awareness that may detect a novel fraud pattern even without explicit training. An AI agent follows its programmed detection rules precisely and fails precisely where those rules have gaps. The fraud scenario library is the mechanism by which those gaps are systematically identified, documented, and closed.

The adversarial nature of fraud means that a static detection system degrades over time. Detection rules that are effective against current fraud patterns become ineffective as attackers adapt. The half-life of a fraud detection rule depends on the sophistication and motivation of the attackers — in high-value domains like financial services and cryptocurrency, attackers adapt within months of a new detection rule being widely deployed. The fraud scenario library creates a living knowledge base that tracks the evolving threat landscape and drives continuous updates to detection logic.

Compound fraud scenarios represent a particularly dangerous gap in many detection systems. Individual transaction validation may pass for each step of a multi-step fraud — the beneficiary change is legitimate, the payout request is legitimate, the amount is within limits — but the combination and sequencing of these steps constitutes a recognisable fraud pattern. Detecting compound patterns requires explicit scenario modelling; they cannot be caught by single-transaction validation rules alone. The fraud scenario library must therefore include not only individual fraud patterns but also combinations, sequences, and timing-based patterns that span multiple transactions or agent interactions.

The AI agent context introduces fraud scenarios that do not exist in traditional financial operations. Prompt injection attacks that cause an agent to bypass its financial controls, social engineering attacks that exploit a customer-facing agent's helpful disposition, and manipulation of external data feeds that the agent trusts (price oracles, identity verification services, document verification APIs) are all attack vectors unique to or amplified by agent-mediated operations. The fraud scenario library must explicitly cover these AI-specific vectors, not only traditional financial fraud patterns.

Regulatory expectations reinforce the need for a governed fraud scenario library. The FCA expects firms to maintain effective systems and controls for fraud prevention that evolve with the threat landscape. DORA requires financial entities to incorporate threat intelligence into their ICT risk management framework. The EU AI Act requires risk management systems that address reasonably foreseeable misuse — which includes adversarial exploitation of AI agents for financial fraud. In every case, regulators expect the organisation to demonstrate awareness of current threats and active measures to address them. A static, deployment-era set of fraud rules does not meet this expectation.

The connection between the fraud scenario library and testing is essential. AG-420 (Tabletop Exercise Governance) and AG-429 (Social Engineering Attack Simulation Governance) both require realistic, current scenarios for their exercises. The fraud scenario library is the primary source of these scenarios. Without a governed library, exercises use ad-hoc scenarios that may not reflect current threats, producing false confidence in the organisation's defences. With a governed library, exercises are systematically informed by actual threat intelligence, and exercise findings feed back into the library — creating a continuous improvement loop.

6. Implementation Guidance

A fraud scenario library is a structured, version-controlled knowledge base. Each entry describes a fraud scenario in sufficient detail to inform detection rules, test cases, and training materials. The library should be machine-readable to enable automated integration with detection systems, while also human-readable to support analyst review and tabletop exercises.

Recommended patterns:

• Structured scenario schema. Define a standardised schema for library entries. Each entry should include: scenario ID, scenario name, MITRE ATT&CK-style kill chain (for multi-step attacks), preconditions, indicators of compromise (IOCs), detection rules (mapped to AG-025 detection logic), defensive measures, affected agent profiles, severity rating, confidence level, source references, date added, and date last validated. The schema should support both simple scenarios (single transaction fraud) and compound scenarios (multi-step attack chains with timing and sequencing information).
• Tiered scenario classification. Classify scenarios into tiers: Tier 1 — confirmed patterns observed in the organisation's operations or directly applicable industry peers; Tier 2 — patterns documented in industry intelligence that are plausible in the organisation's operational context; Tier 3 — emerging or theoretical patterns from adversarial research that have not yet been observed in the wild but are technically feasible. Tier classification determines update priority: Tier 1 scenarios require immediate detection rule implementation; Tier 2 scenarios require detection rule implementation within 30 days; Tier 3 scenarios require risk assessment and monitoring.
• External intelligence integration pipeline. Establish a systematic pipeline for ingesting external fraud intelligence: subscribe to relevant industry fraud intelligence feeds (financial services ISACs, cryptocurrency security alert services, payment network fraud bulletins, regulatory fraud alerts), assign analysts to review new intelligence on a defined cadence (weekly for high-volume feeds, monthly for lower-volume sources), and convert relevant intelligence into library entries following the standardised schema. The pipeline should track intelligence from ingestion to library entry to detection rule implementation.
• Scenario-to-detection traceability matrix. Maintain an explicit mapping from every library scenario to its corresponding detection rules, agent constraints, or compensating controls. The matrix should be bidirectional: for any scenario, you can find the detection rule; for any detection rule, you can find the scenario that motivated it. This traceability ensures that no scenario exists without a defensive response and no detection rule exists without a documented threat basis.
• Periodic scenario validation. At least annually, validate each scenario in the library: is the scenario still relevant (has the underlying vulnerability been eliminated)? Is the detection rule still effective (has the attack evolved to bypass it)? Has the scenario been observed in the wild since the last validation? Expired scenarios should be archived (not deleted) with a rationale for retirement. This prevents the library from growing unboundedly while maintaining historical records.

Anti-patterns to avoid:

• Static scenario lists. Defining fraud scenarios at deployment and never updating them. The threat landscape evolves continuously; a scenario list that is 12 months old has significant gaps against current attack patterns. Static lists create a false sense of security.
• Detection-only scenarios. Documenting fraud patterns solely for detection purposes without considering prevention. For each scenario, the library should document both detection indicators (how to identify the attack in progress or after the fact) and preventive measures (how to make the attack infeasible or ineffective). Detection without prevention means the organisation identifies fraud but cannot stop it.
• Technology-generic scenarios. Using fraud scenarios from traditional financial operations without adapting them for the AI agent context. Traditional "suspicious wire transfer" scenarios do not capture the unique attack surface of an AI agent — prompt injection, decision input manipulation, autonomy boundary exploitation. The library must include AI-agent-specific scenarios.
• Unvalidated external intelligence. Adding every external fraud alert to the library without assessing its applicability to the organisation's operational context. A crypto exchange fraud pattern is not relevant to a traditional insurance company's claims processing agent (and vice versa). Each external intelligence item should be assessed for applicability before conversion to a library entry.
• Scenario hoarding without testing. Building a large library of scenarios that have never been tested against the actual detection systems. A scenario that exists in the library but has never been simulated against the agent's detection logic provides no assurance. Every scenario should be tested at least once, ideally annually.

Industry Considerations

Financial Services. Financial services firms face the broadest fraud scenario landscape: payment fraud, invoice fraud, identity fraud, authorised push payment fraud, insider trading signals, money laundering typologies, and sanctions evasion patterns. Firms should align their library with the fraud typologies published by their national financial intelligence unit (e.g., UK NCA, US FinCEN) and their payment network (e.g., SWIFT CSCF fraud scenarios). Agents processing client payments must have scenario coverage for authorised push payment fraud — a pattern where the agent is socially engineered into processing a legitimate-looking payment to a fraudulent account.

Insurance. Insurance-specific scenarios include: claims inflation (genuine claim with inflated amounts), staged claims (fabricated events), ghost claims (claims for non-existent policyholders), beneficiary fraud (unauthorised beneficiary changes followed by claims), and rehabilitation fraud (claimant recovered but continues claiming). Customer-facing agents processing claims must have specific scenario coverage for each of these patterns, including compound scenarios where multiple patterns are combined.

Crypto and Digital Assets. The DeFi fraud scenario landscape includes: flash loan attacks, oracle manipulation, reentrancy exploits, front-running and sandwich attacks, rug pulls, governance attacks, bridge exploits, and social engineering of wallet signers. The pace of novel attack discovery in this domain exceeds traditional financial services — organisations should review DeFi security post-mortems weekly and update the library accordingly. Agents interacting with smart contracts must have scenario coverage for all documented contract-level attack vectors relevant to their operational protocols.

E-Commerce and Retail. Agents processing purchases, refunds, and loyalty programmes face scenarios including: refund fraud (returning counterfeit items), loyalty point manipulation, discount code abuse, card-not-present fraud, and friendly fraud (legitimate purchases disputed as unauthorised). Compound scenarios include account takeover followed by loyalty point redemption followed by refund request.

Maturity Model

Basic Implementation — The organisation has a documented fraud scenario library with at least 20 scenarios relevant to its agent operations. Each scenario follows a standardised structure with at minimum: description, detection indicators, and defensive measures. The library is reviewed and updated at least quarterly. Each scenario is mapped to at least one detection rule or agent constraint. The library is version-controlled. This level meets the minimum mandatory requirements.

Intermediate Implementation — All basic capabilities plus: the library contains at least 50 scenarios including compound multi-step patterns and AI-agent-specific scenarios. An external intelligence integration pipeline systematically ingests fraud alerts from at least 3 industry sources. A scenario-to-detection traceability matrix is maintained and validated. Each scenario has been tested against the detection system at least once. A scenario effectiveness register tracks detection rule trigger rates and false positive rates. The library is reviewed monthly, with quarterly comprehensive updates.

Advanced Implementation — All intermediate capabilities plus: scenario simulation capability allows automated testing of all library scenarios against detection systems on a scheduled basis (at least monthly). Machine-learning-assisted scenario generation proposes novel scenarios based on transaction pattern analysis. The organisation participates in industry information-sharing frameworks. The library contains 100+ scenarios with tiered classification. Coverage assessments are conducted semi-annually against published fraud taxonomies. Real-time dashboards show library coverage metrics, detection rule effectiveness, and intelligence pipeline throughput.

7. Evidence Requirements

Required artefacts:

• Fraud scenario library. The current version of the complete library, in structured format, showing all scenarios with their full schema fields. Must be provided as a structured data export (JSON, YAML, or database export), not a prose summary.
• Library version history. Complete version history showing all additions, modifications, and retirements of scenarios, with timestamps, authors, and change rationale. Minimum: all versions since initial creation or 3 years, whichever is shorter.
• Scenario-to-detection traceability matrix. The current mapping from every scenario to its corresponding detection rules, agent constraints, or compensating controls, with evidence that each mapped control is implemented and operational.
• External intelligence ingestion records. Records of external fraud intelligence reviewed, including: source, date reviewed, assessment outcome (added to library, assessed as not applicable, deferred for further analysis), and the analyst who performed the assessment.
• Quarterly update records. Documentation of each quarterly library review, including: new scenarios added, existing scenarios modified, scenarios retired, intelligence sources reviewed, and coverage gaps identified.
• Annual coverage assessment. The most recent annual assessment evaluating library coverage against published fraud taxonomies, the organisation's incident history, and the current threat landscape. Must identify any gaps and the remediation plan.
• Scenario testing records. Records of scenario simulation testing, showing for each tested scenario: test date, detection rule triggered (yes/no), detection latency, false positive rate, and remediation actions for failed tests.

Retention requirements:

• Library versions and update records: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise.
• Scenario testing records: same retention as library versions.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. Sensitive scenario details (specific detection bypass techniques) may be provided under restricted access controls, but the existence and structure of the library must be fully disclosed.

8. Test Specification

Test 8.1: Library Structure and Completeness Validation

• Stimulus: Export the fraud scenario library and validate each entry against the required schema (Requirement 4.2). Verify that all mandatory fields are populated for every scenario.
• Expected behaviour: Every scenario in the library contains all required fields: unique identifier, name, attack description, preconditions, detection indicators, defensive measures, applicable agent profiles, severity rating, source reference, and date added.
• Pass criteria: 100% of scenarios have all mandatory fields populated with substantive content (not placeholder text). Zero incomplete entries.
• Fail criteria: Any scenario is missing a mandatory field, or any field contains placeholder or empty content.

Test 8.2: Scenario-to-Detection Mapping Verification

• Stimulus: For each scenario in the library, verify that the mapped detection rule, agent constraint, or compensating control exists, is implemented, and is operational. For a representative sample of at least 10 scenarios, trigger the corresponding detection rule with a simulated attack matching the scenario description.
• Expected behaviour: Every scenario maps to an implemented and operational defensive measure. The simulated attacks trigger the corresponding detection rules.
• Pass criteria: 100% of scenarios have a valid mapping to an operational control. At least 90% of simulated attacks trigger the corresponding detection rule within the defined detection window.
• Fail criteria: Any scenario lacks a mapping to an operational control, or fewer than 90% of simulated attacks are detected.

Test 8.3: Compound Scenario Coverage

• Stimulus: Review the library for compound fraud scenarios — multi-step patterns where individual steps are each legitimate but the combination constitutes fraud. Verify that at least 5 compound scenarios exist, each documenting the step sequence, timing, and the detection logic that identifies the compound pattern (not just the individual steps).
• Expected behaviour: The library contains at least 5 compound scenarios with explicit step-by-step documentation and compound detection logic.
• Pass criteria: At least 5 compound scenarios exist. Each documents the step sequence and the compound detection mechanism. At least 2 compound scenarios have been tested through simulation.
• Fail criteria: Fewer than 5 compound scenarios exist, or compound scenarios describe only individual steps without compound detection logic.

Test 8.4: Quarterly Update Compliance

• Stimulus: Examine library update records for the past 12 months. Verify that at least 4 quarterly updates occurred, each incorporating new intelligence from external sources.
• Expected behaviour: The library was updated at least 4 times in the past 12 months. Each update is documented with: date, new scenarios added, sources reviewed, and analyst responsible.
• Pass criteria: At least 4 documented quarterly updates in the past 12 months. Each update references at least 2 external intelligence sources reviewed. At least 3 new scenarios were added across the 4 quarters (demonstrating active evolution, not rubber-stamp reviews).
• Fail criteria: Fewer than 4 quarterly updates, or any update lacks documentation of external sources reviewed, or zero new scenarios were added in 12 months.

Test 8.5: AI-Agent-Specific Scenario Coverage

• Stimulus: Review the library for scenarios specific to AI agent attack vectors: prompt injection attacks targeting financial controls, social engineering of customer-facing agents, manipulation of agent decision inputs (price feeds, identity data, document verification), and exploitation of agent autonomy boundaries.
• Expected behaviour: The library contains at least 4 AI-agent-specific scenarios covering distinct attack categories.
• Pass criteria: At least 4 AI-agent-specific scenarios exist, covering at least 3 of the 4 listed attack categories. Each scenario includes agent-specific detection indicators (not generic financial fraud indicators).
• Fail criteria: Fewer than 4 AI-agent-specific scenarios, or fewer than 3 attack categories covered, or scenarios use only generic detection indicators without agent-specific adaptation.

Test 8.6: Library Versioning and Immutability

• Stimulus: Retrieve a historical library version by its version identifier. Compare its content against the archived version. Attempt to modify a historical version.
• Expected behaviour: Historical versions are immutable and match their archived copies. Modification attempts are rejected.
• Pass criteria: Retrieved historical version matches the archive. Modification attempt is rejected or logged as an integrity violation.
• Fail criteria: Any historical version has been modified, or modification of historical versions is permitted without detection.

Test 8.7: Annual Coverage Assessment Execution

• Stimulus: Verify that an annual coverage assessment was conducted within the past 12 months. Review the assessment for: comparison against published fraud taxonomies, identification of coverage gaps, and remediation plan for identified gaps.
• Expected behaviour: An annual coverage assessment exists, is dated within the past 12 months, and includes all required elements.
• Pass criteria: Assessment exists and is current. Assessment references at least 2 external fraud taxonomies or published threat reports. Assessment identifies at least one coverage gap (or explicitly documents that no gaps were found with supporting analysis). Any identified gaps have a documented remediation plan with a target date.
• Fail criteria: No annual assessment exists, or the assessment is older than 12 months, or the assessment does not reference external fraud taxonomies, or identified gaps have no remediation plan.

Conformance Scoring

• Score 0: No fraud scenario library exists — fraud detection operates against implicit, undocumented assumptions about threat patterns, with no structured knowledge base, no update process, and no scenario-to-detection mapping.
• Score 1: A fraud scenario library exists with at least 15 documented scenarios, each following a basic structure. The library is version-controlled. Scenarios are mapped to detection rules. However, updates are infrequent (less than quarterly), compound scenarios are absent, and AI-agent-specific scenarios are not included.
• Score 2: The library is updated at least quarterly with external intelligence. Compound fraud scenarios and AI-agent-specific scenarios are included. A scenario-to-detection traceability matrix is maintained. Each scenario has been tested at least once. An annual coverage assessment has been conducted. The library contains at least 40 scenarios covering the organisation's operational fraud landscape.
• Score 3: Verified through independent assessment — the library is comprehensive (75+ scenarios), continuously updated (monthly reviews, quarterly comprehensive updates), and tested through automated scenario simulation. External intelligence is systematically ingested through a documented pipeline. Scenario effectiveness metrics are tracked and reported. Coverage assessments are conducted semi-annually. The organisation participates in industry information sharing. Independent red-team exercises have validated that the library covers the attack vectors they attempt.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 15 (Accuracy, Robustness and Cybersecurity)	Direct requirement
SOX	Section 404 (Internal Controls Over Financial Reporting)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
FCA SYSC	3.2.6R (Financial Crime)	Direct requirement
NIST AI RMF	MANAGE 2.2, GOVERN 1.5	Supports compliance
ISO 42001	Clause 6.1 (Actions to Address Risks)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Direct requirement
DORA	Article 26 (Threat-Led Penetration Testing)	Supports compliance

EU AI Act — Article 15 (Accuracy, Robustness and Cybersecurity)

Article 15 requires that high-risk AI systems are resilient against attempts by unauthorised third parties to exploit system vulnerabilities, including through adversarial manipulation. Financial fraud perpetrated through or against AI agents is precisely the type of adversarial exploitation that Article 15 addresses. A governed fraud scenario library is the knowledge base that informs resilience measures — without systematically catalogued threat scenarios, the organisation cannot demonstrate that it has addressed the adversarial risks Article 15 requires. The library's inclusion of AI-agent-specific attack vectors (prompt injection targeting financial controls, social engineering of agent interfaces) directly addresses the cybersecurity resilience requirements.

FCA SYSC — 3.2.6R (Financial Crime) and 6.1.1R (Systems and Controls)

The FCA requires firms to establish, implement, and maintain adequate policies, procedures, and systems and controls for countering the risk of financial crime. SYSC 3.2.6R specifically addresses financial crime risk management. A fraud scenario library is the structured knowledge base that underpins the firm's fraud risk assessment — it documents the threats the firm defends against, the detection mechanisms in place, and the gaps that require attention. The FCA's expectation is that firms' fraud prevention measures evolve with the threat landscape; a static set of detection rules does not meet this expectation. AG-462's quarterly update requirement and annual coverage assessment directly address the FCA's expectation of continuous evolution.

SOX — Section 404 (Internal Controls Over Financial Reporting)

While SOX does not explicitly require a fraud scenario library, the PCAOB's auditing standards (particularly AS 2401 — Consideration of Fraud in a Financial Statement Audit) require auditors to assess the risk of material misstatement due to fraud. An organisation's fraud scenario library, particularly its coverage of agent-mediated financial processing fraud, informs the auditor's fraud risk assessment. Organisations that can demonstrate a comprehensive, current fraud scenario library with scenario-to-detection traceability provide auditors with evidence that fraud risks are systematically identified and mitigated — supporting a favourable assessment of internal controls.

DORA — Article 9 (ICT Risk Management Framework) and Article 26 (Threat-Led Penetration Testing)

DORA Article 9 requires financial entities to maintain an ICT risk management framework that includes identification, protection, detection, response, and recovery capabilities. The fraud scenario library directly supports the identification and detection functions — it identifies the threats and informs the detection mechanisms. DORA Article 26 requires threat-led penetration testing (TLPT) for significant financial entities, using realistic threat scenarios based on current threat intelligence. The fraud scenario library provides the scenario basis for TLPT exercises targeting agent-mediated financial operations. Without a governed library, TLPT exercises lack systematic scenario coverage and may test against outdated or incomplete threat models.

NIST AI RMF — MANAGE 2.2 and GOVERN 1.5

MANAGE 2.2 addresses mechanisms for tracking identified AI risks. The fraud scenario library is a risk tracking mechanism — each scenario represents an identified risk with documented detection and mitigation measures. GOVERN 1.5 addresses processes for ongoing monitoring and review of AI risk management. The library's quarterly update cycle, annual coverage assessment, and scenario effectiveness tracking collectively implement the continuous monitoring that GOVERN 1.5 requires.

ISO 42001 — Clause 6.1 (Actions to Address Risks)

ISO 42001 requires organisations to identify risks associated with AI systems and implement actions to address those risks. Financial fraud perpetrated through AI agents is a risk that requires structured identification (the fraud scenario library), treatment (detection rules and agent constraints mapped to each scenario), and monitoring (scenario effectiveness tracking and coverage assessments). The library provides the systematic risk identification that Clause 6.1 requires, rather than relying on ad-hoc risk identification.

10. Failure Severity

Field	Value
Severity Rating	High
Blast Radius	Organisation-wide financial operations — an incomplete or outdated fraud scenario library creates blind spots across all agents with financial capabilities, with the blast radius proportional to the value and volume of transactions processed

Consequence chain: The fraud scenario library is absent, outdated, or incomplete, creating gaps in the organisation's understanding of the fraud threats targeting its agent-mediated financial operations. The immediate failure is invisible: no alarm fires when a fraud scenario is missing from the library — the absence is only discovered when the corresponding attack succeeds. The operational consequence is that agents process transactions without detection rules for known fraud patterns, allowing preventable fraud to succeed. The financial impact depends on the value and volume of transactions: in Scenario A, £523,000 in invoice duplication fraud over 11 months; in Scenario B, £67,000 in a single beneficiary fraud event; in Scenario C, $184,000 in a single flash loan exploit. The regulatory consequence compounds the financial loss: regulators expect organisations to defend against known threats. When an attack succeeds using a well-documented pattern that was absent from the organisation's fraud defences, regulators view this as a control failure — the organisation should have known about the threat and failed to address it. This transforms a fraud loss into a regulatory finding, potentially triggering enforcement action, increased supervisory scrutiny, and required remediation programmes. The reputational consequence follows: customers, counterparties, and market participants lose confidence in an organisation that fails to defend against documented attack patterns. For organisations in the crypto and digital asset space, where security reputation directly affects protocol TVL (total value locked) and user trust, the reputational consequence may exceed the direct financial loss by an order of magnitude. The systemic consequence is that without a governed library, each fraud incident is treated as a surprise rather than a failure to implement known defences — the organisation does not learn systematically, and the same category of attack may succeed repeatedly through different specific variants.

Cross-references: AG-025 (Financial Fraud Detection) provides the detection framework that the fraud scenario library informs. AG-438 (Jailbreak Pattern Library Governance) provides the analogous library for prompt injection and jailbreak patterns, which may overlap with agent-specific fraud scenarios involving prompt injection to bypass financial controls. AG-463 (Treasury Exposure Limit Governance) defines exposure limits that fraud scenarios may attempt to circumvent. AG-464 (Reconciliation Break Escalation Governance) may detect the downstream effects of successful fraud that evaded scenario-based detection. AG-466 (Invoice Authenticity Verification Governance) addresses invoice fraud prevention, which is a major category within the fraud scenario library. AG-029 (Invoice & Payment Fraud Detection) implements detection for invoice and payment fraud scenarios. AG-420 (Tabletop Exercise Governance) uses fraud scenarios as the basis for tabletop exercises. AG-429 (Social Engineering Attack Simulation Governance) uses social engineering fraud scenarios for simulation exercises.