Checked on August 27, 2026. Regulated solutions require specialized legal and compliance review.
AI-powered fraud and anomaly detection ranks events by risk to stop a harmful action or route the case to an analyst. An anomaly is only a deviation from normal behavior, not proof of intent. That is why production anti-fraud systems combine rules, models, graph relationships, external signals, and human review.
In brief: Define the protected event, the acceptable delay, and the action for each risk level. Train on data available before the decision, and measure financial losses and review workload. Blocking should not be based on an unexplained anomaly score without policies, confirmation, and an appeals process.
Contents
- Anomaly, risk, and confirmed fraud
- Which signals to use
- Anti-fraud architecture
- Rules, models, and graphs
- How to choose a threshold
- Which metrics to track
- Human review and feedback
- Monitoring and attacks on the model
- Pilot plan
- FAQ
- How AI Sunrise implements anti-fraud
- Bottom line
Anomaly, risk, and confirmed fraud
An unusual transfer may be a legitimate large purchase. A payment that looks normal on the surface may be part of a scheme familiar to attackers. The system should distinguish three separate entities:
- anomaly score — how much the event differs from normal;
- risk score — an estimate of probability or expected loss;
- case outcome — the result of an investigation, dispute, or chargeback.
Only the last one creates a label, and often with delay and errors. Do not call every unverified alert fraud: that distorts training and reporting.
Which signals to use
Useful signals include amount, speed and sequence of actions, device, channel, geography, recipient, changes in payment details, relationships between accounts, and the history of confirmed cases. Context matters more than any single feature: a new phone alone is weak, but a new phone plus an access change and an atypical transfer may require review.
Collect only justified data, limit access, and define retention periods. Sensitive attributes and automated actions with significant consequences should undergo legal review.
Anti-fraud architecture
The flow looks like this: event → enrichment with fresh features → rules and models → policy engine → approve, additional verification, delay, or manual case → outcome → feedback store.
Separate score from action. The same risk can lead to different measures depending on the amount, the customer, the law, and analyst availability. For each response, define an SLA, reason codes, and a fallback if the model is unavailable.
Rules, models, and graphs
Rules quickly cover known schemes and provide a transparent baseline. A supervised model is useful when you have enough confirmed labels. Unsupervised anomaly detection finds new deviations, but creates more investigations. Graph analysis helps reveal shared devices, recipients, and chains.
These layers complement each other. Launch any new model in shadow mode first, comparing it with rules and analyst decisions without affecting the customer.
How to choose a threshold
The threshold depends on more than the ROC curve. Consider expected loss from misses, the cost of false stops, transaction amount, latency, and team capacity. A multi-level policy is practical:
| Risk | Possible action |
|---|---|
| low | allow and log |
| medium | request additional confirmation |
| high | temporarily hold and open a case |
| critical | apply the approved protective measure |
This is a design example, not a universal legal rule.
Which metrics to track
Accuracy is almost useless when fraud is rare. You need precision and recall at the operating threshold, PR-AUC, review rate, latency, prevented and missed loss, false-positive cost, investigation time, and performance by segment.
The Bank of Russia reports that in 2025 banks prevented 134.16 million transactions made without customers’ voluntary consent; at the same time, the number of completed fraudulent transactions increased (official review). The scale shows how important anti-fraud is, but it is not a benchmark for an individual company.
Human review and feedback
The analyst interface should show the event, relevant context, relationships, and reason codes, but not push the user to blindly confirm the score. Separate “suspicion,” “confirmed by the customer,” “confirmed by investigation,” and “system error.”
The NIST AI RMF Playbook recommends defining roles and accountability for oversight throughout the system lifecycle (NIST). You need a policy owner, a model owner, an investigations team, and an appeal path.
Monitoring and attacks on the model
Fraudsters adapt, so performance changes faster than in typical ML. Monitor feature drift, new clusters, fallback rate, label latency, queue precision, overrides, and complaints. Compare the current policy with a frozen champion and review the rules regularly.
Protect features and models from leakage: a published threshold or exact reasons can help bypass the system. In an incident, a kill switch, a safe rules-only mode, and investigation of the decision version should be available.
Pilot plan
- Choose one event type and one protective action.
- Set a baseline for losses, false positives, and SLA.
- Verify labels and the temporal availability of features.
- Assemble the rules and a simple model.
- Run shadow scoring and an analyst queue.
- Tune thresholds based on capacity and error cost.
- Conduct a limited launch with rollback and case reviews.
FAQ
Can fraud be detected without labeled data?
You can look for anomalies and relationships, but those signals require validation. To measure real fraud, you need confirmed outcomes.
Why does the model create so many false alarms?
Fraud is rare, behavior changes, and the threshold may not account for capacity. Check the base rate, features, segments, and policy.
Can a customer be blocked automatically?
That depends on the law, the risk, and internal policy. Material actions require justification, oversight, logging, and an accessible review process.
How often should the model be retrained?
Based on observed drift and the speed of scheme changes, not on a calendar. Between training cycles, rules and thresholds can be updated through a controlled process.
How AI Sunrise implements anti-fraud
AI Sunrise starts with one transaction type: it records losses, current rules, SLA, constraints, and the acceptance criterion. Then the team can:
- collect temporal features and verified outcomes;
- implement rules, ML, and graph signals;
- build in case management, reason codes, and feedback;
- run a shadow pilot, a limited rollout, and handoff of procedures.
Conclusion
AI-powered antifraud is a decisioning and investigation framework, not a binary classifier. Separate anomalies from confirmed fraud, set thresholds based on loss and capacity, preserve human review and a safe rollback path. Start with one event and expand automation only based on verified results.