AI Fraud Detection in Banking: Fraud Alerts, Risk Scores and Investigative Evidence
AI fraud detection can identify suspicious behaviour at a scale and speed that manual investigation cannot match. But a fraud alert or risk score is not an investigative finding. The critical practitioner question is what behaviour produced the output, what the underlying evidence establishes, and which competing explanations remain credible.
Key Points
- AI and machine-learning models can materially strengthen fraud detection by identifying behavioural departures, transaction patterns, network relationships and other risk signals across volumes of data that cannot realistically be reviewed manually. Their value, however, depends on maintaining a clear boundary between detection and investigation. A fraud risk score is a model output produced for a defined purpose; it is not, by itself, proof that fraud occurred.
- For investigators, the analytical task is to move behind the score. That means identifying the behaviour that generated or materially influenced the alert, understanding the baseline against which that behaviour was assessed, establishing what relevant information sits outside the model, and testing credible alternative explanations. False positives matter because they demonstrate that behaviour can satisfy a detection methodology without being fraudulent in fact.
- For control owners, the relationship should work in reverse. Investigation outcomes can reveal false-positive drivers, missed behaviours, emerging typologies, data-quality problems, model blind spots and weaknesses in alert presentation. Model performance and investigative performance are therefore connected but not interchangeable. The relevant question is not simply whether AI generates better alerts, but whether the overall detection-and-investigation architecture produces better and more defensible fraud decisions.
Introduction
Artificial intelligence is becoming part of the operating architecture of fraud detection in banking. Machine-learning models and other analytical systems can process transaction histories, behavioural changes, device information, beneficiary relationships and network patterns at a scale that manual investigation cannot replicate. They can identify activity that differs from expected behaviour, prioritise transactions for intervention and direct scarce investigative resources towards accounts, payments or relationships assessed as presenting greater risk.
This is no longer a marginal use case. The Bank of England and FCA 2024 survey of AI in UK financialservices found that 75% of respondent firms were already using AI and a further 10% planned to use it within three years. Large UK and international banks reported substantially more use cases than the overall median, while the Bank of England later noted that firms were using AI particularly for internal-process optimisation, cybersecurity and fraud detection.
The investigative difficulty begins when the output of that technology is given more meaning than it can support. A model can correctly identify that behaviour is unusual without establishing why it is unusual. It can rank a transaction as high risk without proving that the transaction is fraudulent. It can identify an association between accounts without establishing the nature of that relationship, the knowledge of the parties involved or whether the relationship is causally relevant to the suspected fraud.
The distinction is consistent with the UK's Government Counter Fraud Profession Standard for FraudDetection Practitioners, which treats detection as a process for identifying indications of fraud and requires subsequent evaluation capable of distinguishing fraud from error, false positives and legitimate activity. The standard is written for public-sector counter-fraud practice rather than banking, but its separation of detection from evaluation is directly useful to the evidential problem created by AI-enabled alerts.
The risk becomes more significant as detection systems become more sophisticated. Investigators readily understand that a simple threshold rule is only an indicator. A model that combines many variables and returns a precise-looking score can appear more authoritative. Yet apparent numerical precision does not tell the investigator how much evidential weight should be assigned to the output. A model can be highly confident that a pattern exists without establishing what that pattern means. The central practitioner problem is therefore not whether AI belongs in fraud detection, but how institutions preserve the boundary between model output, investigative hypothesis and evidential conclusion.
AI Fraud Detection Is Becoming Mainstream Banking Infrastructure
ECB Banking Supervision reported in November 2025 that AI use cases among significant European institutions increased between 2023 and 2024, including applications in fraud detection. Its annual data collection covered 107 significant institutions in 2023 and 110 in 2024. A separate set of workshops with 13 selected banks examined AI applications and governance in greater detail; the ECB expressly cautioned that findings from that smaller sample should not be generalised across the entire sector.
Within the 13-bank workshop sample, decision-tree models were used for credit scoring and fraud detection, while neural networks were mainly associated with fraud detection. The ECB identified potential benefits in real-time monitoring and pattern recognition, allowing suspicious activity to be identified earlier and potentially reducing manual review. At the same time, its supervisory discussion focused on explainability, model governance, data quality, operational resilience, third-party dependence and human oversight. The significance for practitioners is that greater detection capability and stronger governance are developing together; one does not eliminate the need for the other.
The UK evidence points in the same direction. The Bank of England and FCA's AI Public-Private Forum final report organised its analysis around data, model risk and governance, reflecting the fact that problems can enter at the data stage, arise through modelling choices or emerge through the way systems are governed and used. The later Bank of England/FCA feedback statement FS2/23 recorded industry concerns about explainability, third-party models, data bias, model complexity and the need for robust human oversight as AI becomes more influential in financial decision-making.
The FCA's Supercharged Sandbox now provides a controlled environment for firms to develop and test AI use cases. Its 2026 cohort includes propositions intended to detect fraud and economic crime more effectively and strengthen AI governance and accountability. This does not constitute FCA approval of individual products, but it illustrates how fraud detection has moved from theoretical AI discussion into active experimentation and deployment.
For investigators, however, the important distinction sits below the technology-policy debate. Detection identifies activity that warrants attention according to a control's design. Investigation reconstructs events, evaluates evidence, tests competing explanations and determines what can responsibly be concluded. An effective model may substantially improve case selection without resolving the investigative question. Conflating the two functions risks converting model confidence into evidential confidence.
What Does a Fraud Risk Score Actually Tell the Investigator?
A score of 94, for example, should not automatically be interpreted as a 94% probability that fraud occurred. Some systems may produce calibrated probabilities; others produce rankings, classifications or proprietary composite scores. A threshold may be designed to optimise a particular operational trade-off rather than express a factual probability. Investigators need to understand what the particular output represents before using it in decision-making, especially where a score is subsequently repeated in case files, customer interventions or escalation decisions.
Consider an illustrative payment receiving a high risk score because it is materially larger than the customer's normal transactions, involves a new beneficiary, follows a recently observed device change and occurs after a departure from the customer's established behavioural pattern. Those observations may justify immediate scrutiny. They do not necessarily establish the fraud mechanism. The account may have been taken over; the legitimate customer may be making an unusual but genuine payment; the customer may control the account but have been deceived into making the transfer; another authorised person may be operating the account; or a genuine change in circumstances may have produced behaviour the model has not previously observed.
The 2026 US interagency model-risk framework reinforces the importance of appropriate use. The Federal Reserve's SR 26-2 and the corresponding OCC Bulletin 2026-13 replace earlier model-risk guidance and emphasise risk-based model development, use, validation, monitoring, governance and controls. The guidance also makes clear that a model can create risk through inappropriate use even where it is fundamentally sound. It excludes generative and agentic AI from scope, so it should not be presented as comprehensive US AI regulation; its relevance here is the narrower model-governance principle that accurate outputs can still be misapplied.
That distinction is particularly relevant because the Federal Reserve told Congress in March 2026 that banks have used mature machine-learning capabilities for years, including in fraud detection and prevention, while newer generative and agentic AI applications were generally being explored in lower-risk areas. Fraud investigators therefore need to distinguish the established use of predictive and classification models from newer AI categories that may present different risks and operating characteristics.
Agentic AI creates a further investigative distinction when the technology moves from identifying or prioritising suspicious activity to taking delegated financial action. In agentic payments, the evidential question can extend beyond what an AI system detected to what authority an AI agent possessed, what decision it made and whether the resulting transaction remained within the customer's mandate. This emerging problem is examined in When AI Agents Move Money: Investigating Authority, Intent and Fraud in Agentic Payments.
The Score Is Not the Evidence
The practical consequence is that investigators need to move from the score to the underlying signals. A new beneficiary is an observable account event. A significant increase in payment velocity is an observable behavioural change. A previously unseen device may be a relevant technical event. A relationship between an account and a known fraud network may be an analytical association. A score combining those observations is a model output derived from them. These categories have different evidential characteristics and should not be collapsed into a single proposition that 'the AI identified fraud'.
The distinction matters when information is repeated across systems. Suppose an alert score is driven partly by a new device and an unusual beneficiary, and the case-management system then presents the score, device change and beneficiary novelty as three separate risk indicators. These are not necessarily three independent pieces of corroboration. The score may already incorporate the other two observations. Treating derived outputs and their underlying inputs as independent evidence can artificially inflate the apparent weight of a case.
This extends the evidential discipline developed in Fraud Intelligence Lab's earlier proposition that fraud indicators are not evidence. AI increases the sophistication with which indicators can be generated, combined and prioritised; it does not abolish the distinction between an indicator and a finding. The practitioner question is therefore not simply whether the model scored the activity highly, but what observable behaviour materially influenced the assessment, what that behaviour establishes independently of the model, and what additional evidence is required to distinguish between competing explanations.
False Positives Are More Than an Efficiency Problem
False positives are usually discussed as an operational burden. Excessive alert volumes consume investigator capacity, increase queues, generate unnecessary customer friction and can divert attention from genuinely material cases. Those effects matter, but viewing false positives only through the lens of productivity misses their analytical significance. A false positive demonstrates that behaviour can resemble fraud according to a detection method without being fraudulent in fact.
The PSFA practitioner standard explicitly requires practitioners to distinguish legitimate activity, false positives, error and fraud. Its wider process model also places outcome evaluation, action and review after detection. For banking practitioners, the transferable lesson is that the control's ability to identify risk must remain separate from the investigator's responsibility to determine what explanation the evidence supports.
This should change the way an AI-generated alert is approached. If the enquiry begins with 'how do I prove that this alert is fraud?', the model has already shaped the conclusion before the evidence has been tested. A stronger formulation is: what explanation best accounts for the behaviour that caused this alert? The difference is operationally important. The first question encourages confirmation; the second requires hypothesis testing.
False-positive analysis should also be more granular than a single rate. Control owners should ask which customer behaviours repeatedly create false alerts, whether particular segments are disproportionately affected, whether certain features are driving avoidable friction, whether the baseline is stale, and whether investigators are closing cases for consistent reasons. A falling false-positive rate may represent improved calibration, but it can also conceal reduced sensitivity if the model has become less responsive to emerging fraud. Precision must therefore be interpreted alongside coverage and missed-fraud analysis.
Data Quality, Drift and the Problem of a Moving Baseline
AI fraud detection is only as reliable as the information and assumptions on which it operates. The Bank of England and FCA 2024 AI survey identified data privacy and protection, data quality and data security among the leading risks perceived by respondent firms, while model complexity and third-party dependencies were expected to become more significant. The ECB's 2025 supervisory work likewise noted that only a few banks in its workshop sample reported effectively applying data-management standards to AI models and emphasised that poor inputs can produce unreliable results.
For investigators, data quality is not an abstract model-governance issue. Missing, delayed or incorrectly linked data can alter which behaviour is visible and therefore which hypothesis appears most plausible. A device may look new because historical device identifiers were not retained consistently. A beneficiary may appear novel because accounts have been migrated. A customer's behaviour may look anomalous because the baseline excludes activity from another channel. The investigator needs to know when apparent behavioural novelty could be partly a data artefact.
Drift creates a related problem. Customer behaviour, products, channels and fraud methodologies change over time. A model trained or calibrated against historical relationships may lose relevance as legitimate behaviour evolves or criminals adapt. Model monitoring may identify statistical deterioration, but investigation provides a different form of evidence: repeated cases in which the same new fraud sequence appears, or repeated false positives arising from a legitimate behaviour that has become common. These case-level patterns can reveal that the model's representation of risk is moving out of alignment with operational reality.
The wider governance principle is consistent with the NIST AI Risk Management Framework, which treats validity and reliability, accountability and transparency, explainability and interpretability, privacy, security and fairness as context-dependent characteristics of trustworthy AI. NIST's framework is voluntary and non-sector-specific, so it does not establish banking requirements. Its value here is as a structured reminder that model quality is multidimensional: a technically powerful system can still be poorly governed, insufficiently interpretable or unreliable in a changed context.
The F.I.L. Model-to-Investigation Evidence Chain
Source: Fraud Intelligence Lab (F.I.L.) original analytical framework. It is not a statutory test, regulatory model or law-enforcement investigation standard.
Model Output and Signal Interpretation
The chain begins with the output presented to the investigator: an alert, risk score, anomaly score, classification, network association or other system-generated result. At this point, the practitioner should record what the output actually represents according to the model's purpose rather than infer more from it than the system is designed to establish. A high-risk classification establishes that the system classified the activity as high risk according to its data and logic; it does not establish that an investigation has confirmed fraud.
Signal interpretation then moves behind the output to the behaviour that materially influenced it. The relevant factors might include an unusual transaction sequence, a new beneficiary, a device change, geographic inconsistency, an unexpected relationship with other accounts or a departure from the customer's behavioural baseline. This transition matters because the score itself is difficult to investigate; the underlying behaviours can be tested. A control architecture in which investigators routinely receive risk scores but cannot identify the material reasons for case prioritisation may possess strong detection capability while offering weak investigative interpretability.
Investigative Hypothesis and Enrichment
Once the material signals have been identified, they should be translated into one or more testable investigative hypotheses. A new device followed by an unusual payment may support an account-takeover hypothesis, but it may also be consistent with a legitimate device change. Successful customer authentication may weaken some forms of account-takeover hypothesis while leaving open the possibility that the customer was socially engineered into authorising the payment. A suspicious beneficiary relationship may suggest coordination, but the nature and knowledge associated with that relationship still require investigation.
The purpose of competing hypotheses is not to create artificial doubt around obvious fraud. It is to prevent the first plausible explanation, particularly one implied by the model, from becoming the only explanation considered. Investigators should identify credible alternatives where the available evidence supports them and then seek information capable of discriminating between those explanations.
Enrichment introduces evidence that the model did not contain, could not access or was not designed to interpret. Depending on the case, this might include customer contact, authentication records, account history, communications, beneficiary intelligence, device and session data, linked-account activity, previous investigations, external intelligence or subsequent movement of funds. Every model operates within an information boundary. What the model cannot see may be as important to the investigation as what it can.
Corroboration, Refutation and Disposition
Enriched information should then be tested against the competing hypotheses. Investigators should ask not merely whether a new fact is consistent with fraud, because many weak indicators can satisfy that description. The stronger question is whether the information materially increases or decreases the evidential weight of a particular explanation relative to credible alternatives.
Suppose beneficiary novelty contributed to an alert. Subsequent analysis establishes that the beneficiary account has received similar payments from multiple unrelated customers followed by rapid onward dispersal to connected accounts. That additional information materially changes the evidential assessment. Conversely, suppose the beneficiary is independently verified as a long-established professional service provider, the payment corresponds with documentary evidence of a genuine transaction, and customer contact produces an explanation consistent with independently available records. The original anomaly remains real, but its significance changes.
Disposition should capture that reasoning. A defensible case record should explain what the evidence establishes, what remains unresolved, which alternative explanations were considered and why the final outcome is proportionate. The strength of the conclusion should reflect the strength of the evidence rather than the numerical precision of the original score. Another competent practitioner should be able to understand the disposition without having to accept the model output as self-validating.
Model Feedback
The evidence chain should not terminate when the case closes. Investigation generates intelligence about the performance of detection controls. Confirmed fraud can expose useful behavioural sequences and emerging typologies. False positives can identify features that are overweighted or insufficiently contextualised. Fraud detected through complaints, external intelligence or another control may reveal behaviours that the model failed to identify. Repeated legitimate explanations may show that a customer's evolving behaviour is being interpreted against an outdated baseline.
This creates a reciprocal relationship between detection and investigation. Detection should improve the selection and prioritisation of cases, while investigation should improve understanding of what the detection architecture sees, misses or misinterprets. Where investigative dispositions disappear into a case-management system without reaching fraud-intelligence teams, model owners or control-calibration processes, the institution loses one of the most valuable sources of real-world feedback available to it.
Explainability Does Not Mean the Fraud Has Been Explained
Explainability matters because investigators, model owners and control functions need sufficient understanding of why a system behaves as it does. ECB Banking Supervision reported that most banks in its 13-bank workshop sample used explainability tools to monitor model performance, while some institutions appeared to lack full transparency into the internal processes of certain models. The ECB also reported human oversight around high-risk decisions and real-time fraud alerts.
The UK's PRA Supervisory Statement SS1/23 takes a broader model-risk approach built around model identification and classification, governance, development and use, independent validation and model-risk mitigants. The current version, effective from 23 April 2026, expressly recognises the need to identify and manage risks associated with artificial intelligence in modelling techniques such as machine learning to the extent those risks fall within model use.
For investigators, however, explainability has a boundary. If an explanation shows that beneficiary novelty, transaction velocity and device characteristics materially influenced a risk score, the practitioner has learned why the model produced its output. That does not necessarily explain why the transaction occurred. The second question may require evidence about account control, customer intention, communications, deception, beneficiary conduct and subsequent funds movement that was never available to the model.
The distinction can therefore be expressed succinctly: model explainability explains the output; investigation explains the event. This does not diminish the importance of explainability. Investigators may need sufficient visibility of model drivers to formulate meaningful hypotheses. It simply prevents technical transparency from being mistaken for factual reconstruction. A completely explainable model can still produce an alert whose underlying event remains ambiguous until additional evidence is obtained.
The F.I.L. Fraud Alert Challenge Framework
Source: Fraud Intelligence Lab (F.I.L.) original analytical framework. It is not a statutory test, regulatory model or law-enforcement investigation standard.
Trigger and Baseline
The first question is what materially triggered the alert. 'The customer scored high risk' is not an adequate investigative description if the underlying drivers can reasonably be identified. A more useful statement might be that the system identified a material departure from the customer's transaction pattern involving a new beneficiary, unusual payment velocity and a recently observed device. The latter gives the investigator observable behaviour capable of enrichment and testing.
The second question is the baseline against which the behaviour was judged. An anomaly exists only relative to a comparison: the customer's own history, a peer population, known fraud cases, network behaviour or another reference point. That matters because behaviour that is unusual for one customer may be routine for another. Historical baselines are also backward-looking. They can help identify change, but they should not create an assumption that past behaviour defines the limits of legitimate future behaviour.
Blind Spots and Alternative Explanations
Every model has a field of view. A transaction model may observe a payment but not the communication that induced it. A device model may identify a new handset without knowing that the customer legitimately replaced their phone. A network model may identify an association without establishing the nature of the relationship. A beneficiary-risk model may observe suspicious downstream movement while having little visibility of what the original payer knew. The investigator should therefore ask what material part of the suspected fraud mechanism sits outside the model's inputs or analytical purpose.
This is particularly important in APP fraud. A model may observe an unusual payment, new beneficiary and departure from normal transaction behaviour while having no visibility of the social-engineering conversation that shaped the customer's payment decision. Authentication evidence may establish that the customer completed the relevant authentication process, but neither the transaction score nor the authentication event necessarily resolves whether deception influenced payment intent. The model's blind spot therefore becomes part of the investigative plan rather than an assumed absence of evidence.
Alternative explanations should then be developed where credible. This is a principal defence against confirmation bias. The objective is not to invent implausible innocent explanations for suspicious conduct, but to test whether the fraud hypothesis explains the evidence better than realistic alternatives. Where proportionate enquiry progressively refutes those alternatives, the evidential weight of the fraud hypothesis increases. Where a legitimate explanation is independently corroborated, the original alert may still have been technically correct in identifying unusual behaviour even though the suspected fraud explanation is not sustained.
Independent Evidence and Feedback
Investigative enrichment should seek information capable of changing the assessment rather than merely repeating the model's inputs in different forms. If a model score is driven by device change and beneficiary novelty, reporting those same two factors again does not create independent corroboration. Stronger evidence is information that helps distinguish between competing hypotheses: communications evidencing social engineering, device information supporting compromise, independently verified beneficiary details, customer testimony consistent with external records, linked-account behaviour or subsequent movement of funds.
The final question is what the case should teach the control. A confirmed fraud case may validate an existing typology or reveal a new behavioural sequence. A false positive may expose recurring legitimate behaviour that the model treats as suspicious. A case first identified through a customer report may show that important fraud behaviour remained outside the model's coverage. A successful investigation may uncover a network relationship that was invisible at transaction level. Capturing those lessons transforms individual dispositions into fraud intelligence rather than allowing cases to become isolated operational outcomes.
Model Performance Is Not Investigative Performance
One of the most consequential control mistakes is assuming that better model metrics automatically produce better fraud investigation. A model might reduce false positives while becoming less effective against a newly emerging fraud methodology. Alert volumes might decline because calibration has improved, because customer behaviour has changed or because relevant criminal behaviour has moved outside the model's coverage. Conversely, an increase in alerts could reflect deteriorating precision, a genuine increase in attempted fraud or successful detection of an emerging typology. The metric cannot explain its own cause.
The same problem arises with case outcomes. A high proportion of alerts resulting in fraud dispositions might indicate strong detection precision, but it could also reflect an investigative process that gives excessive weight to the model's initial classification. A low conversion rate might indicate poor targeting, or it might reflect appropriate intervention at a stage where evidence remains limited. Control owners therefore need to understand the decision process behind performance measures rather than treating individual metrics as self-explanatory.
The Bank of England's 2025 Financial Stability in Focus report on AI provides a broader systemic perspective: common weaknesses in model and data risk management can become vulnerabilities when many firms rely on similar components, data or models. Although that analysis concerns financial stability rather than fraud investigation, it reinforces the importance of looking beyond a single model's headline performance and examining dependencies, common failure modes and the wider control environment.
A more useful fraud-control evaluation examines the complete detection-investigation lifecycle. What material fraud behaviours is the model designed to detect? What remains outside its coverage? Can investigators understand material alert drivers? Which legitimate behaviours repeatedly create false positives? How are fraud cases first identified outside the model analysed retrospectively? Are missed cases converted into typology and calibration work? Can investigators distinguish model-derived information from genuinely independent corroboration? Do dispositions feed back into control development? These questions connect technical performance to operational effectiveness.
Human Oversight Must Mean More Than Human Approval
Human-in-the-loop language is frequently presented as a safeguard in AI governance, but the phrase can conceal substantial differences in practice. A human who simply accepts or rejects a machine-generated recommendation provides human involvement, but not necessarily meaningful investigative challenge. If the model determines the initial hypothesis, the evidence presented, the risk classification and the recommended action, an investigator may technically make the final decision while exercising very little independent analytical judgement.
This concern is consistent with themes in the Bank of England/FCA FS2/23 feedback statement, where respondents highlighted the need for robust governance and human oversight as firms become more reliant on AI systems for decision-making and critical tasks. The document is a summary of stakeholder responses rather than a statement of new regulatory requirements, so it should be read as evidence of industry concerns rather than as a binding standard.
Meaningful oversight requires the practitioner to be able to interrogate the output. The investigator needs sufficient information to understand what behaviour generated the alert, what baseline informed it, what relevant information is absent, what fraud hypothesis the behaviour supports, what evidence contradicts that hypothesis and what further enquiry could materially change the assessment. Human oversight therefore depends not only on staffing but on information access, investigative capability and authority to challenge the detection result.
The 2026 US interagency guidance uses the concept of effective challenge in model governance. That concept should not be presented as a fraud-investigation standard, but it illustrates a wider control principle: sophisticated model outputs should remain capable of critical challenge rather than becoming self-validating because of their complexity. At case level, if an investigator cannot explain which behaviour materially influenced the alert, what evidence supports the suspected mechanism, what information weakens that explanation and why the final disposition follows from the evidence, human oversight may exist procedurally without adding much investigative value.
Automation Bias Can Distort the Investigation
The complexity of AI systems creates a related investigative risk. A simple rule such as 'new beneficiary plus payment above threshold' exposes its logic immediately. Investigators can see its limitations and are unlikely to mistake the rule itself for proof. A machine-learning score generated from numerous variables may appear more authoritative precisely because the reasoning is less visible and the output more technically sophisticated.
The danger does not require an investigator consciously believing that an algorithm is infallible. More subtle anchoring is sufficient. A high score can influence the first fraud hypothesis; the first hypothesis can determine which enquiries are prioritised; those enquiries determine which evidence is discovered; and the resulting evidence may then appear to validate the original classification. If alternative explanations were never seriously tested, the investigation can become circular even though each individual step appears reasonable.
The control against automation bias is not distrust of technology. It is disciplined hypothesis testing. The model should help direct attention towards potentially significant behaviour, but the investigator should remain capable of asking what else could account for that behaviour and what evidence would distinguish the explanations. Institutions should also examine whether case-management interfaces inadvertently amplify automation bias by foregrounding risk scores while obscuring model limitations, data quality warnings or alternative contextual information.
Investigators Should Test What the Model Missed
Fraud-alert review naturally concentrates on why a system triggered, but the inverse question can be equally important: what relevant behaviour did the model fail to represent? Models operate against available data, engineered features, defined objectives and historical information. Criminal behaviour does not have to remain inside those boundaries.
An APP fraud model may detect transaction anomalies while having no access to the communications through which the customer was manipulated. An account-level model may regard an individual receiving account as relatively unremarkable until network analysis reveals that it is connected with multiple accounts receiving proceeds from unrelated victims. A model trained on historical fraud may underweight a new behavioural sequence deliberately designed to avoid established intervention patterns. None of those scenarios necessarily demonstrates a defective model; they demonstrate that detection coverage has boundaries.
The EBA's June 2026 Risk Assessment Report places this problem in a broader operational-risk context. It identifies fraud as a major driver of operational risk and notes that AI can benefit fraud detection while also creating risks including operational failure, bias, data-quality problems, cyber exposure, third-party reliance and regulatory uncertainty. The practical implication is that AI can simultaneously strengthen one part of the fraud-control environment and introduce new dependencies that need to be understood and governed.
The investigative implication is significant. Practitioners should ask both what the model saw and what relevant part of the suspected fraud mechanism existed outside its field of view. The second question helps identify evidence that needs to be obtained through enrichment and can expose opportunities for future control development. Investigation thereby becomes a mechanism for discovering model blind spots rather than merely resolving model alerts.
Third-Party Models Create an Investigative Transparency Problem
Banks increasingly rely on external technology, cloud environments, vendor models and specialist data providers. Third-party capability can improve speed of deployment and give institutions access to sophisticated analytics that would be difficult to build internally. But outsourcing model development or infrastructure does not outsource the investigative consequences of the model's output.
The PRA's SS1/23 model-risk principles apply to externally developed models as well as in-house models within their scope, while the 2026 US interagency model-risk guidance expressly discusses vendor and third-party products and the need for appropriate validation. ECB Banking Supervision has also highlighted third-party, cloud and transparency issues in its work on bank AI.
For fraud operations, the practical question is whether investigators receive enough information to understand and challenge a vendor-generated alert. A proprietary score may be commercially protected, but an institution still needs an operational understanding of what the score is intended to represent, what data categories materially affect it, what limitations are known, how changes are controlled and what evidence investigators should obtain before acting. A black-box commercial arrangement can otherwise become a black-box investigative process.
This issue becomes more acute where the vendor model is one layer in a larger decision stack. A bank may combine a third-party device score, internal transaction model, beneficiary-risk service and rule-based interventions into a final case priority. Investigators need to understand enough of that architecture to avoid treating correlated outputs as independent corroboration or assuming that several scores represent several distinct evidential sources.
Data Protection and AI Governance Affect What Investigators Can Reliably Use
The European Data Protection Board's Opinion 28/2024 addresses the processing of personal data in the development and deployment of AI models, including questions of anonymity, legitimate interests and the consequences of unlawful processing. It is not a fraud-detection standard, but it illustrates why data provenance, lawful processing and governance remain relevant when AI outputs depend on personal data.
For investigators, the point is not to turn every case review into a data-protection assessment. It is to recognise that the reliability and permissible use of model outputs can depend on the provenance and governance of the underlying data. If a critical feature is poorly sourced, inconsistently defined or no longer representative, the model's apparent precision may exceed the quality of the information supporting it.
This reinforces the need for separation between model governance and case investigation while maintaining communication between the two. Investigators should not be expected to validate training data or reproduce model-development testing. Model owners should not be expected to determine the facts of individual fraud cases. But where investigations repeatedly expose questionable data, unexplained features or unexpected customer impacts, those findings should be capable of reaching the functions responsible for data, validation and governance.
AI Fraud Detection and the EU AI Act
The EU AI Act requires careful treatment because broad statements that 'banking AI is high risk' can be misleading. Annex III identifies AI systems used to evaluate the creditworthiness of natural persons or establish credit scores as a high-risk use case, but expressly provides an exception for AI systems used for detecting financial fraud. The European Commission's AI Act Service Desk reproduction of Annex III makes that exception explicit.
That exclusion should not be interpreted as meaning that every system described by an institution as fraud detection is outside every relevant AI Act provision or other legal and regulatory requirement. Actual functionality, purpose and deployment matter, particularly where systems perform multiple functions. Data protection, operational resilience, consumer protection, model-risk governance and other obligations may also remain relevant independently of Annex III classification.
For financial-crime practitioners, the more important lesson is methodological. Regulatory analysis should follow the actual system and its use rather than a generic label such as 'AI in banking'. Credit scoring, fraud detection, customer monitoring and automated decision-making can create different legal and control questions even where they rely on related technologies. Precision about the use case is therefore as important in regulatory analysis as precision about the model output is in investigation.
A Practitioner Control Test for AI Fraud Detection
The quality of an AI fraud-detection control should ultimately be judged by more than technical model metrics. Investigators, fraud-intelligence teams, model owners and control leaders should be able to explain how model outputs become cases, how cases become findings and how findings return to the control environment. A practical control review can therefore be organised around six questions.
First, can investigators identify the material behaviours behind a high-risk alert? If not, the institution may be generating prioritisation without sufficient investigative interpretability. Second, can investigators distinguish model-derived information from independently obtained evidence? Without that distinction, the same underlying information can be counted repeatedly and create an illusion of corroboration. Third, are credible alternative explanations actively tested, or are investigations designed primarily to validate the model's initial classification?
Fourth, are false positives analysed by cause rather than simply counted? A false-positive rate describes scale; cause analysis identifies what legitimate behaviour the control misunderstands. Fifth, are missed fraud cases mapped back against model coverage? A control cannot be evaluated only on what it detects. Material cases first identified through complaints, other controls or external intelligence may reveal blind spots. Sixth, can investigation outcomes influence detection? If dispositions disappear into case-management systems without reaching model owners or fraud-intelligence functions, valuable learning is lost.
These questions shift governance away from a narrow focus on model accuracy towards the quality of the complete detection-and-investigation system. They also create a common language between teams that otherwise approach the same control from different perspectives: data science asks whether the model performs; fraud operations ask whether alerts are workable; investigators ask what the evidence establishes; model risk asks whether use is appropriate; and leadership asks whether the control reduces loss and customer harm. Effective governance needs all of those questions, not a single metric standing in for them.
Practitioner Guide
For fraud investigators, the principal change is analytical rather than technological. An AI alert should initiate a progression from model output to observable behaviour, from behaviour to investigative hypotheses, and from hypotheses to evidence capable of corroboration or refutation. Investigators do not need to become data scientists to apply that discipline, but they do need sufficient understanding of the detection environment to know what an alert represents, what it does not represent and what material information may sit outside it.
Fraud-intelligence teams should treat investigative outcomes as intelligence about both criminal behaviour and control performance. Repeated false positives can expose legitimate behaviours that detection systems misunderstand. Confirmed cases can identify new sequences, relationships and typologies. Cases first discovered through customer reports, complaints, law-enforcement intelligence or other controls can reveal model blind spots. The intelligence function is therefore well placed to connect individual case learning with wider detection development.
Control owners should resist assessing AI primarily through alert volume or a single accuracy metric. A model that generates fewer alerts is not necessarily better if material fraud is being missed, just as a model generating more alerts is not necessarily worse if it has identified an emerging attack pattern. Performance should be evaluated against intended typology coverage, investigative usability, false-positive causes, missed cases, customer impact and the quality of feedback between investigation and model development.
For model-risk and validation functions, operational use matters alongside technical performance. A technically sound model can still create poor outcomes when users misunderstand the meaning of its outputs, apply scores outside their intended context or lack the information required to challenge them. For financial-crime leadership, this means AI fraud detection cannot be owned solely by data science, fraud operations or model-risk teams. Effective control requires those disciplines to understand where their responsibilities intersect and where their conclusions remain different.
Conclusion
AI can materially strengthen fraud detection in banking. It can analyse transaction and behavioural information at scale, identify patterns that manual review may not reveal, surface relationships across accounts and prioritise activity for intervention. Current official evidence across the UK, European Union and United States shows that financial institutions are already using AI and machine learning in fraud detection while supervisors and standards bodies focus increasingly on model governance, data quality, explainability, validation, third-party dependence and human oversight.
The technology does not remove the evidential problem at the centre of fraud investigation. A risk score expresses a model assessment produced from defined information for a defined purpose. An alert directs attention towards behaviour considered relevant by a detection system. Neither automatically establishes the fraud mechanism, the intention or knowledge of the parties involved, or the explanation that best accounts for the observed activity.
The investigator's task therefore begins where the model output becomes operationally significant. Practitioners need to identify the behaviour behind the alert, understand the baseline against which it was assessed, determine what information remained outside the model, formulate credible competing hypotheses and seek evidence capable of changing the relative weight of those explanations. A defensible disposition should rest on that reasoning rather than on the apparent precision of a score.
The relationship should then operate in reverse. Investigations expose false-positive drivers, emerging typologies, data weaknesses, missed behaviours and model blind spots. Those findings should inform fraud intelligence and, where appropriate, control calibration and model development. AI-supported detection is strongest when the institution recognises that the model and the investigator perform different analytical functions and deliberately connects them.
The objective is not to replace investigative judgement with better risk scores. It is to use better risk scores to direct investigative judgement towards the evidence that matters.
Methodology and Evidential Note
This article draws primarily on official UK, European Union and United States regulatory, supervisory and professional-practice material concerning fraud detection, artificial intelligence, machine learning, model-risk management, data governance and AI risk management. The jurisdictions do not apply identical legal or supervisory frameworks, and references to one jurisdiction are not presented as establishing requirements in another.
The US interagency model-risk material is used for relevant model-governance principles rather than treated as a fraud-investigation standard. The UK Government Counter Fraud Profession standard concerns public-sector counter-fraud practice but is used for its professionally relevant distinction between detection, evaluation, false positives, error and fraud. The NIST AI Risk Management Framework is voluntary and non-sector-specific. The Bank of England/FCA AI Public-Private Forum report reflects the views of participating experts rather than formal regulatory policy, and FS2/23 summarises stakeholder responses rather than introducing new requirements.
The F.I.L. Model-to-Investigation Evidence Chain and F.I.L. Fraud Alert Challenge Framework are original Fraud Intelligence Lab analytical constructs developed to support practitioner reasoning. They are not regulator-issued models, legal tests or industry standards.
Primary References
1.UK Government / Public Sector Fraud Authority — Standard for Fraud Detection Practitioners, 27 May 2025.2. Bank of England and Financial Conduct Authority — Artificial Intelligence in UK Financial Services: 2024 Survey.
3. Bank of England and Financial Conduct Authority — AI Public-Private Forum: Final Report, 17 February 2022.
4. Bank of England / Prudential Regulation Authority / Financial Conduct Authority — FS2/23: Artificial Intelligence and Machine Learning, 26 October 2023.
5. Prudential Regulation Authority — SS1/23: Model Risk Management Principles for Banks, current version effective 23 April 2026.
6. Financial Conduct Authority — Supercharged Sandbox, 2026.
7. ECB Banking Supervision — AI’s Impact on Banking: Use Cases for Credit Scoring and Fraud Detection, 20 November 2025.
8. European Banking Authority — Risk Assessment Report, June 2026.
9. European Union — Regulation (EU) 2024/1689 — Artificial Intelligence Act.
10. European Commission — AI Act Service Desk: Annex III.
11. European Data Protection Board — Opinion 28/2024 on Certain Data Protection Aspects Related to the Processing of Personal Data in the Context of AI Models, 18 December 2024.
12. Federal Reserve — SR 26-2: Revised Guidance on Model Risk Management, 17 April 2026.
13. Office of the Comptroller of the Currency — Bulletin 2026-13: Model Risk Management — Revised Guidance, 17 April 2026.
14. Federal Reserve — Testimony on Innovation and Banks’ Use of AI and Machine Learning, 26 March 2026.
15. National Institute of Standards and Technology — Artificial Intelligence Risk Management Framework (AI RMF 1.0).
16. Bank of England — Financial Stability in Focus: Artificial Intelligence in the Financial System, April 2025.
