Reducing fraud losses

Plain language meaning

Reducing fraud losses explains how AI can help banks detect account takeover, mule activity, synthetic identity, internal misuse, application fraud and unusual account behaviour earlier, while balancing customer friction, investigation capacity and evidence quality.

This topic is about fraud-loss reduction in banking. It is not about blocking every unusual event or confusing fraud prevention with AML, sanctions or credit-risk control.

In a real bank, this topic cannot be handled as a loose data-science or technology idea. It affects customer outcomes, fraud and AML control, operational queues, service continuity, privacy, security, model governance, audit replay, management reporting and regulatory confidence. AI should improve speed and quality, but the bank must still prove source data, permitted use, approved logic, human accountability, fallback handling and retained evidence.

Where it sits in the banking AI journey

This card belongs to Business Impact and Controls. The working flow is Fraud signal, AI risk score, Control action, Investigation outcome, and Loss and feedback.

Read the flow as a bank operating model. Each stage needs a source system, a data owner, a timing rule, a quality gate, a model or rule boundary, an exception path, a customer-impact view, a fallback option, a monitoring requirement and a retained record. That is what separates useful AI adoption from uncontrolled automation.

Banking data and evidence

The important data points are identity signal, device signal, login anomaly, account age, transaction velocity, beneficiary pattern, case outcome, and loss amount. These items matter because they can influence risk scoring, operational repair, fraud action, AML triage, customer treatment, reporting, model monitoring and management decisions.

The evidence pack should include fraud alert, risk score, control action, customer contact note, investigator narrative, loss report, and feedback record. A strong bank can replay the journey from source data to transformed input, AI output, rule result, human action, system outcome and monitoring result. A weak bank only knows that a process ran and hopes the process was right.

Controls that make AI adoption safe

The core controls are risk-based threshold, step-up authentication, case prioritisation, customer contact protocol, investigator review, loss measurement, and feedback governance. These controls keep the topic anchored to banking purpose, approved policy, data governance, model-risk expectations, operational resilience, customer fairness, privacy, security and auditability.

The practical design should define what AI may recommend, what it must never decide alone, which deterministic rule remains authoritative, who owns thresholds and overrides, how degraded service is handled, how customer harm is detected and what evidence is retained. Without that control design, faster AI can simply make weak processes fail faster.

Architecture and data-operation lens

Banking AI depends on the architecture around it. Storage, streams, feature definitions, training sets, model versions, thresholds, feedback labels and rollback paths must be governed before the bank relies on AI output. The model is only one part of the control chain.

A bank-grade design connects channels, source systems, core records, payment hubs where relevant, fraud systems, AML platforms, case tools, data platforms, feature stores, model-serving endpoints, policy engines, audit logs and management dashboards. It also records degraded operation, recovery actions and lessons learned.

Regulatory and governance lens

Federal Reserve SR 26-2, dated 17 April 2026, gives revised model-risk guidance for traditional models and non-generative AI models used by banking organisations, including development, validation, monitoring, change control and governance.

The Federal Reserve's 2026 model-risk guidance states that generative and agentic AI are outside that guidance, while broader bank risk-management and governance practices still need to control tools and processes not covered by the guidance.

NIST AI RMF 1.0 uses Govern, Map, Measure and Manage functions for AI risk management, and NIST AI 600-1 adds generative-AI risk actions for source grounding, content provenance, data protection, cybersecurity and human oversight.

FFIEC Architecture, Infrastructure and Operations guidance expects financial-institution technology environments to be governed, resilient, secure, monitored, documented and aligned to business risk, including emerging technologies such as artificial intelligence and machine learning.

BCBS 239 remains current for effective risk data aggregation and risk reporting, and the Basel Committee's January 2026 newsletter reiterates the importance of accurate, comprehensive and timely data capabilities in banks.

FFIEC BSA/AML examination guidance expects suspicious activity monitoring systems and supporting technology to be risk-based, explainable by management, independently tested where appropriate and aligned to the bank's risk profile.

FinCEN's 12 June 2026 Section 314(b) materials clarify information sharing for possible terrorist activity, money laundering and fraud-related specified unlawful activity within the statutory safe-harbor framework for participating financial institutions.

OFAC's Framework for Compliance Commitments describes sanctions compliance programme components including management commitment, risk assessment, internal controls, testing and auditing, and training.

Diagram walkthrough

Read the diagram from left to right as Fraud signal, AI risk score, Control action, Investigation outcome, and Loss and feedback. It is a banking control map. The point is to show how data, AI or ML output, rules, human action, operational routing and audit evidence should connect.

Use it as a 30-minute study method. For each box, ask which system creates the data, which definition is used, which model or rule acts, what can go wrong, who can override it, how a fallback works, which customer or regulatory impact exists and what record proves the final state.

Most important mistake to avoid

The common failure is measuring fraud AI only by blocked events. A bank must measure avoided loss, confirmed fraud, false positives, customer friction, investigation effort, missed fraud and recovery evidence together.

The correction is disciplined scope. Keep the chapter anchored to banking purpose, prove the data path, make ownership visible, test failure behaviour, record the evidence and make the final outcome explainable without relying on memory, assumptions or developer-only knowledge.

An outcome measure after the alert

A card fraud model may generate a high score, but loss reduction depends on a chain of actions: the score arrives in time, policy decides to challenge or hold, the customer or investigator responds, and the transaction reaches a final outcome. A bank should distinguish gross attempted fraud, prevented loss, realised loss, recovery and operational costs. A prevented amount estimated from every declined high-score transaction would overstate benefit because some would have been legitimate or blocked by another control.

A fictional bank pilots a new alert threshold on one card channel. It records eligible authorizations, model and rule versions, actions, confirmed fraud labels and subsequent chargeback or recovery adjustments. A comparison group helps separate model effect from changing fraud volume, seasonal spend or a separate rule update. Labels take time to mature and may be disputed. Do not treat all unresolved transactions as genuine. Compare customer friction, false positives, manual-review capacity and losses by relevant segment rather than celebrating a single aggregate percentage.

The analyst should trace a disputed case from event time and feature freshness through score, policy action, customer challenge and final disposition. An unavailable feature source may trigger a defined fallback instead of an invented low score. A retry must not release an already blocked transaction or double-count the event. Review whether the model misses fraud types absent from its training population and whether criminals shift channels after a control change.

Set an evaluation window and denominator before the pilot. Report uncertainty and the cost of legitimate transactions wrongly declined. If losses fall while complaints or queue delays rise, the trade-off needs an accountable business decision. The model owner, fraud operations and customer team should review the evidence together. The NIST AI RMF Measure playbook provides a general framework for contextual performance and impact measurement; it does not supply a universal fraud threshold or financial-benefit calculation.

Define the loss before claiming reduction

Fraud loss can mean gross attempted value, settled fraudulent value, net loss after recovery, reimbursement cost or a broader customer and operational impact. These measures are related but not interchangeable. A model may block more attempted value while causing many false holds. A bank should define the outcome, follow-up period, eligible transaction population and ownership of recoveries before claiming that AI reduced losses.

AI can score payment instructions, card authorizations, account takeover signals or suspicious customer behavior. It can rank cases for investigators and help summarize evidence. It does not replace authentication, payment limits, mandatory screening, customer verification or dispute handling. A score becomes useful only through an approved policy and a workflow that can act before funds are irreversibly lost.

The primary unit might be a payment instruction, card authorization, customer episode or fraud case. A single attack can involve multiple attempts and technical retries. Counting attempts as losses or counting each case as one transaction distorts results. Link business IDs, attempted and settled amounts, final statuses, recoveries and confirmed outcomes with dates and source quality.

Fraud types and decision windows

Card-not-present fraud, account takeover, authorized push-payment scams and synthetic identity activity produce different signals and intervention opportunities. A card issuer may decide within milliseconds; a bank can sometimes hold an account-to-account payment for review; a scam victim may have authorized the transfer despite strong authentication. A model trained on one type should not be assumed effective on another.

Define the point at which the bank can still intervene. Features available after a transfer settles can help investigation but cannot justify a pre-settlement score. A case note created during a later dispute is an outcome signal, not an authorization-time feature. Historical backtests must reproduce information available before each action.

Adversaries adapt. They can split payments below value thresholds, rotate devices, establish benign history or switch channels. A static model metric can decay even while the service remains available. Monitor pattern shifts, source quality and policy outcomes, and use domain expertise to challenge new features. Do not automatically retrain on the latest labels without checking selection and maturity.

Data and features

Useful signals can include recent distinct payment count, amount relative to customer history, new beneficiary status, device or session changes, prior verified alerts and network relationships. Each needs an entity, time window, eligible event status, source and freshness rule. A recent-payment count of zero can be real or caused by a stalled stream. A beneficiary mapping error can make a trusted payee appear new or the reverse.

Use point-in-time features. A later chargeback or analyst confirmation must not enter the original vector. A customer-master correction learned tomorrow was not known at today's decision. Record event and availability times, feature version and missingness status. Training and serving should agree on these semantics, and sampled live decisions should be replayed from source records.

Protect sensitive data. Fraud features may reveal payment relationships, locations and account behavior. Give model serving the minimum suitable inputs and restrict raw investigation data. A graph link may be inferred rather than confirmed; preserve relationship type and confidence. Do not expose another person's case details in an explanation to a customer.

Labels and observability

Fraud labels arrive through customer reports, disputes, investigations and external notifications. Some are overturned; others remain unresolved. Define confirmed, suspected, legitimate and unobservable states, with maturity periods. A chargeback can have causes other than fraud. A blocked transfer may never generate the same downstream label as a released one. Report outcome source and revision history.

Selection is central. A model that holds high-risk payments changes which transactions settle and can later produce losses. If every hold is counted as prevented fraud, benefits are overstated. If only settled transactions are evaluated, the model's most consequential actions disappear from analysis. Track eligible, scored, held, challenged, released and settled populations separately.

Mature-cohort reporting groups transactions by decision date and observes them after a consistent follow-up window. Recent transactions can show action and source-quality metrics, but confirmed loss may be incomplete. Compare model and policy versions under similar traffic, stating changes in mix and observation. A raw decline in monthly loss may reflect fewer transactions, a different fraud campaign or more holds.

Model and policy evaluation

Measure ranking quality, calibration where a probability is claimed, precision and recall at plausible thresholds, and performance by product and segment. Then simulate the policy: how many cases are referred, how quickly they can be reviewed, how much confirmed loss is caught, and how many legitimate customers are delayed? A classifier's area-under-curve metric does not measure the final fraud outcome.

Value matters. A model may catch many small events yet miss a few large losses. Report transaction counts and amounts, including distribution tails. Recovery can reduce net loss, but it may involve time and customer effort. A model that shifts losses from bank to customer without improving prevention is not an unqualified success. Define the bank's outcome and customer protections.

False positives impose costs: payments held, declined purchases, account freezes, support contacts and loss of trust. Measure time to resolution and whether a customer could access help. Thresholds should be chosen with fraud, operations, customer and risk owners, not solely by optimizing a statistical curve. Segmented policies need fairness and legal review.

Orchestration

The fraud model supplies a score or abstention. A policy engine applies thresholds, value limits, authentication results and other rules. Mandatory screening and legal holds are separate. A low fraud score cannot clear a sanctions match. A high fraud score may trigger a challenge or human review rather than automatic permanent rejection. Record the score, feature validity, policy version, action and final payment state.

Latency matters. A 200-millisecond payment decision must allocate time to features, model, policy and logging. A late model response should not change a settled instruction. If the feature store or model times out, use an approved fallback with bounded loss and friction, not a silent zero score. A manual queue has finite capacity during an outage.

Idempotency matters too. A payment retry can cause multiple model calls but should produce one business action. A duplicated stream event can inflate velocity and create false holds. Reconcile instruction IDs, attempts, case records and settlement. A technically healthy scoring service can still be surrounded by defective data or decision handling.

Account takeover example

An attacker gains access to a customer's online session and attempts a first transfer to a new beneficiary. The model sees device change, beneficiary novelty and recent transfer behavior. A policy can challenge or hold the payment, while authentication and account controls apply independently. A reviewer needs source evidence and a safe customer-contact procedure; a score alone does not establish who initiated the transfer.

If the customer confirms the instruction, the model's high score may be a false alarm, but confirmation quality matters. A scam victim might genuinely authorize a transfer under manipulation. The bank should distinguish account takeover from authorized scam and evaluate the intervention appropriate to each. One generic fraud label can obscure these differences.

The decision log links device event, feature snapshot, model score, policy, challenge result, analyst action and payment status. A later customer report can revise the outcome. Investigation should not overwrite the original decision context. Reverse lineage helps find other payments affected by a device feed or beneficiary mapping defect.

Authorized scam example

A customer instructs a large transfer to a newly added payee after being deceived. Authentication may be valid. A model can identify unusual amount, destination or timing, but a binary "authorized" field is not proof of safety. A well-designed intervention may present a tailored warning or route to trained staff before settlement, subject to local rules and bank policy.

Measure whether the warning changes confirmed scam outcomes and how many legitimate transfers it interrupts. A generic warning shown to everyone can cause habituation. A model's confidence does not justify inventing facts about the beneficiary. Preserve the prompt or warning version, customer response and final action. A later loss analysis should separate scams from unauthorized transactions.

Operational cases

Fraud analysts can use model ranking to prioritize cases, but case capacity and evidence access determine effect. A score that creates 1,000 referrals for a team able to resolve 200 may delay genuinely urgent cases. Measure oldest case, time to action, confirmed fraud value and false holds. A model that flags risk after the payment is irrevocable may aid recovery rather than prevention; report that contribution separately.

Human overrides should have reasons. An analyst may have new evidence, recognize a trusted relationship or identify bad source data. Route data defects to source owners and policy exceptions to governance. Do not treat all overrides as ground-truth labels for retraining. Sample cases for quality and consistency.

Customer operations need accurate statuses. A held payment should not be communicated as settled. A returned payment should be reconciled and explained through the proper channel. Fraud detection can reduce losses while increasing customer friction; both should appear in management reporting.

Economic measurement

Compare gross attempted fraud, settled confirmed fraud, recoveries and net loss over a defined mature horizon. Report eligible transaction volume and value, model coverage, fallback rates, action distribution and false-positive burden. A before-and-after comparison needs adjustment or at least disclosure for changes in traffic, fraud campaigns, policy and channel mix.

Estimate incremental benefit against current rules or model, not against a fictitious no-control world. Shadow scoring compares predictions but cannot directly show what would have happened under changed actions. A bounded live rollout with safeguards can provide stronger evidence, but fraudsters and customers may respond to the intervention. State assumptions and uncertainty.

Prevented loss is counterfactual. A held suspicious transfer might have been canceled for another reason; a declined card authorization might have been legitimate. Use confirmed investigations, sampled reviews and plausible bounds rather than counting all held value as saved. Include recovery and reimbursement outcomes where relevant.

Fairness and segment review

Fraud patterns and source availability vary by channel, customer tenure, location and product. New customers may lack history features and receive more referrals. A branch or accessibility channel may have different device data. Evaluate holds, false positives, review time and loss by relevant groups under legal and privacy governance. A common threshold can yield unequal experience when features are systematically missing.

Review mechanisms for contesting a false hold and correcting data. A wrong identity link can contaminate a network feature across customers. The bank should identify affected decisions and resolve actual outcomes, not just retrain the model. Explain the payment status in usable terms without revealing confidential detection rules or other customers' information.

Monitoring and incidents

Monitor source lag, feature validity, score distribution, action rate, case age, customer complaints and mature fraud outcomes. A sudden fall in scores may reflect a stale counter, not safer traffic. A rise in confirmed losses with stable scores may reflect a new attack or weak threshold. Diagnose source, model, policy and operational capacity separately.

If a source defect is found, invoke an approved limited mode, enumerate affected decisions and compare original with corrected features. Review actual releases and holds, customer impacts and potential recovery actions. Replaying a stream can repair present state but must not re-execute past payments. Keep incident and remediation evidence.

Controlled improvement

Develop a candidate on point-in-time data with mature labels and time-aware validation. Compare to current controls at realistic workload and transaction value. Test missing inputs, adversarial splitting, source migration and high-volume periods. Shadow it before changing actions, then use a bounded rollout with predeclared stop criteria and customer guardrails.

The final scorecard should show whether net confirmed loss fell, whether legitimate payments suffered more friction, whether review queues stayed workable and whether high-risk segments were covered. A model can be technically impressive yet fail this broader test. Fraud-loss reduction is credible when the bank can attribute better outcomes to a controlled AI decision path while accounting for uncertainty and the customers it inconvenienced.

Loss-accounting example

Imagine 100,000 eligible transfers worth a total of 50 million units during a month. The model scores 98,000; 2,000 use an approved fallback. Policy holds 500 scored transfers worth 700,000 units and releases the rest after independent controls. Investigators later confirm 80 held transfers as attempted fraud worth 120,000 units. Another 40 held transfers remain unresolved. Confirmed fraudulent settled transfers produce gross losses of 90,000 units, of which 30,000 is recovered. These figures describe different stages, not one net benefit number.

The bank should not report the entire 700,000 held value as saved. Some holds are legitimate, some remain unresolved and some attempted fraud might have failed for another reason. It can report confirmed attempted value stopped, mature net settled loss, recoveries and uncertainty around other holds. It should also report false holds, median release time and customer complaints. A comparison with the prior policy needs similar transaction mix and label maturity.

Reconcile those populations by business ID. The 2,000 fallback transfers need their own actions and outcomes. The 40 unresolved holds should not be silently labeled legitimate or fraudulent. Recoveries may occur after the first report and require a revised period view. The model's actual contribution is the incremental difference from existing controls, which may be estimated with a controlled comparison or careful assumptions.

Evaluating thresholds with capacity

Suppose a lower fraud threshold raises referrals from 500 to 1,500 per day, but analysts can resolve only 700. A retrospective model metric may show more fraud candidates captured, yet the live queue grows and high-severity cases may wait. Simulate arrivals by hour and case duration, including weekends and incident peaks. A priority ranking and tiered review can help, but the policy must define what happens to lower-priority cases and when escalation occurs.

Measure detection before the decision deadline. A case completed after settlement may support recovery, not prevention. Compare prevented settlement loss, recovered loss and investigative intelligence separately. If a model gives a high score only after a delayed feature update, its offline recall overstates real-time utility. Use recorded feature and response times in evaluation.

Set limits on customer friction. A bank can reduce observed settled fraud by holding nearly every payment, but that is not a viable service. Report legitimate holds per confirmed fraudulent hold, duration, abandoned payments and support contacts. Some customer groups may be more affected because source data is missing. Threshold review should include segment effects and a practical remedy for false holds.

False negatives and missed populations

Review confirmed fraud that the model scored low, but also investigate cases the model never scored because of invalid inputs, outages or scope exclusions. A high recall on scored transactions can mask a concentrated gap in a new channel. Report eligible, covered and excluded populations. Sample scope boundaries and inspect adversarial behavior that exploits them.

For each missed confirmed case, ask whether the relevant signal existed before decision, whether the source delivered it on time, whether the feature computed correctly, whether the model used it and whether policy acted on the score. A feature store outage needs a different remedy from an unrecognized scam pattern. Do not automatically add a high-cardinality identifier or sensitive field without assessing privacy, stability and fairness.

Customer reports may reveal a fraud type that the existing label taxonomy missed. Update definitions and historical analysis carefully. A new category can make the apparent fraud rate rise even if underlying behavior does not. Preserve label versions and explain reporting changes.

False positives and customer trust

Sample legitimate payments that were held or declined. Check whether source features were valid, whether the threshold was appropriate and whether the customer received a clear route to resolve the hold. Measure repeated interruptions for the same customer, including whether a prior verification should have updated beneficiary or device reference data. A model can repeatedly penalize a customer because a correction never reaches the feature store.

False positives have distributional effects. A thin-history customer may receive more holds because absence of data is treated as suspicious. A customer using an accessibility channel may lack device signals. Review rates and resolution times by relevant groups under privacy governance. A model should abstain or use a validated alternative where inputs are unreliable; it should not invent reassuring zeros.

Human review can also create false negatives. If an analyst releases a high-score payment under time pressure without seeing the underlying evidence, model quality is not the only issue. Capture override reasons, training and queue conditions. A bank should evaluate the whole fraud operating system, not assign every outcome to the model.

Learning after deployment

Fraud patterns evolve, and the model changes observed data by holding payments. Maintain independent quality sampling where appropriate, monitor attack narratives and use mature outcomes. A retrained model requires point-in-time features, selection-aware evaluation and validation. A vendor's automatic refresh should not replace bank approval for consequential action.

Separate source, model and policy changes in the release record. If fraud losses rise after a threshold change, inspect action volumes and case capacity. If scores shift after a customer-master migration, inspect mappings. If confirmed loss rises with stable data and policy, investigate new tactics and calibration. The remedy should follow evidence.

Maintain rollback and degraded modes. An older model may need an older feature version; a rule-only path has different risk and customer effects. Test both before incidents. After a rollback, preserve decisions made under the candidate, identify affected customers and reconcile cases. The payment ledger's actual status remains authoritative.

Independent review exercise

Ask a reviewer to select one confirmed blocked attempt, one confirmed settled fraud, one false hold, one model timeout and one payment missed because of invalid features. For each, reconstruct the source events available at decision time, feature vector and validity, model output, policy branch, analyst action, final payment state and later outcome. The reviewer should explain which losses were preventable before settlement and which were only recoverable afterward.

Then query all decisions made during a simulated source defect and classify exposure, score change, action change and confirmed customer impact. Compare a proposed model update with existing rules at a workload analysts can handle. If the evidence cannot support a credible incremental loss estimate, report that uncertainty and improve measurement before making a larger claim.

Counterfactual limits

To estimate incremental loss avoided, the bank needs an idea of what would have happened under the prior policy. A shadow model can score the same payments without acting, giving a clean comparison of predictions and potential workload. It cannot tell whether a customer would have completed a challenged payment or whether an attacker would have changed tactics. A bounded live comparison can provide stronger evidence, but its design must respect customer treatment and mandatory controls. State which outcomes are observed and which are modeled.

When using historical replay, apply the candidate only to features that were available at the original decision time. A later confirmed-fraud label can evaluate the result but cannot be a candidate feature. Preserve old policy actions, because they shaped which payments settled and acquired labels. A naive replay that treats blocked payments as confirmed fraud will overstate benefits.

Use ranges for uncertain quantities. One estimate might count only confirmed fraudulent attempts stopped; another might include a fraction of unresolved suspicious holds under stated assumptions. Show how the conclusion changes. Do not turn a model score into a dollar saving by multiplying every high-score transaction by its amount. The bank may still choose a safer policy under uncertainty, but it should not claim a precise financial effect without evidence.

Response to a new attack

Suppose fraudsters begin sending many low-value transfers to newly created beneficiaries. A model trained on large single payments may miss them. Analysts observe a cluster of customer reports and linked counterparties. The team first verifies that the event stream and identity mapping are complete, then builds point-in-time aggregate features for distinct beneficiaries and combined value. It tests whether those features would have been available before settlement, how they behave for legitimate customers and whether they increase case volume.

An emergency rule may limit the pattern while a candidate model is developed. The rule has a scope, owner and expiry. The model goes through validation and a controlled rollout; its impact is measured against the rule-enhanced baseline, not the obsolete pre-attack process. Keep source, policy and model changes distinct so later loss analysis can attribute effects cautiously.

Watch adaptation after rollout. Attackers may spread transactions across accounts or move beyond the chosen window. Monitor network patterns and sampled misses, but avoid expanding data collection indiscriminately. A new graph feature can rely on uncertain entity links and affect innocent customers. Validation should include false merges, privacy constraints and a fallback when network data is stale.

Governance of loss claims

When a team reports that AI reduced fraud loss, the review pack should include metric definition, denominator, source reconciliation, model and policy versions, comparison method, mature outcome window, recoveries, false-positive burden and uncertainty. Show the total eligible population, including unscored and fallback requests. Break out product and channel mix. A claim based only on model-detected cases omits customers the model failed to cover.

Business owners should sign off on the loss definition and customer treatment. Model validation should challenge leakage and selection. Fraud operations should confirm queue capacity and case quality. Finance or an independent analyst should reconcile monetary amounts and recovery timing. Privacy and fairness review should examine where interventions fall. These roles bring different evidence to one conclusion.

Schedule a later review for delayed reports and recoveries. If the confirmed loss estimate changes, publish the revision with its reason. Retain the original decision and outcome versions. A bank's ability to revise an estimate transparently is stronger evidence than an unchanging headline number that ignores late information. Include a sample of legitimate customers whose payments were interrupted. Their resolution time and experience belong beside the loss number, because a prevention policy must remain workable for the people it protects. Recheck the scorecard after a source migration or model update; yesterday's gain does not automatically survive changed data. Record which fraud patterns were outside model scope, and do not attribute changes in those losses to the model. Keep attempted, prevented, settled and recovered amounts in separate fields so a later reviewer can reproduce the calculation. Publish the number of unresolved investigations alongside the estimate to show how much outcome uncertainty remains. Reconcile model fallbacks and unscored eligible payments too; otherwise a loss claim can hide a channel where the model did not operate.

Reconcile prevented and settled amounts

A model holds 100 transfers worth 200,000 units. Investigators confirm 20 attempted fraud cases worth 50,000, release 60 legitimate payments and leave 20 unresolved at the cutoff. The bank cannot claim all 200,000 as loss avoided. Report confirmed attempted value stopped, mature net settled loss, recoveries, false-hold duration and unresolved cases separately. Compare against existing controls under similar traffic and state the counterfactual uncertainty.

Review a missed confirmed fraud that scored low and another payment never scored because a feature feed was stale. The first may reveal model or policy weakness; the second needs source and fallback repair. Link original feature, score, policy action and final status for both. A credible loss claim accounts for the full eligible population and customer friction. Revisit unresolved investigations after the agreed outcome window and revise net loss after recoveries. Distinguish a confirmed attempted fraud from an assumed prevented loss. If the model's coverage excludes one channel, do not attribute that channel's loss trend to the new system.