Fraud detection and prevention workflow
Real-time detection, risk scoring, blocking, and manual review of suspicious transactions.
Fraud is expensive: stolen cards cost you chargebacks, refunds, and reputation damage. Real-time fraud detection catches attacks before they scale. This template shows how to build a layered defense: velocity checks (rate limit card usage), geolocation anomalies (impossible travel), amount anomalies (spending outside user norms), and a risk score that combines signals into a decision (block, challenge with 2FA, approve, or send for manual review).
The key insight: fraud is predictable in aggregate. Fraudsters test cards rapidly; they use multiple cards in quick succession; they try different amounts to find what works. Legitimate users have stable, repeatable patterns. A risk score that weighs velocity, location, and amount catches attacks in real-time, before the fraudster gets their money.
When to use this template
- Payments system design — sketch detection rules before building, so engineering and fraud teams agree on what signals matter and how aggressively to block.
- Risk modeling — map every fraud scenario (card testing, account takeover, carding) to detection rules so no gap goes unaddressed.
- Incident response — when fraud spikes, trace which signals missed the attack and tighten thresholds. Use this diagram to document the changes.
How to adapt it
Customize detection rules for your domain:
- Card testing campaigns — a fraudster tests a batch of stolen card numbers with small charges ($0.99, $1.99). Add a rule: if 10+ cards from the same IP fail within 5 minutes, block the IP for an hour.
- Account takeover detection — legitimate users rarely change password or email. Add a rule: if login fails 5 times in 5 minutes from a new IP, lock the account and send email verification.
- Chargeback feedback loop — when a user disputes a transaction (chargeback), lower that merchant's risk threshold or block them. Add a feedback step that updates models based on chargebacks.
Visual edits regenerate clean Mermaid code, so you can sketch custom detection rules and share them with your security team.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Transaction received] --> B[Extract risk signals]
B --> C[Check velocity rules]
C -->|Too many attempts| D[Block transaction]
D --> E[Log fraud event]
E --> F[Alert user]
F --> G[Return 429 Too Many Requests]
C -->|Normal velocity| H[Check geolocation]
H -->|Impossible travel| D
H -->|Reasonable location| I[Check amount anomaly]
I -->|Exceeds user history| J[Get risk score]
I -->|Normal amount| J
J --> K{Risk score}
K -->|Critical| D
K -->|High| L[Request 2FA challenge]
L -->|Passed| M[Approve transaction]
L -->|Failed| D
K -->|Medium| N[Flag for manual review]
N --> O[Queue in review system]
O --> M
K -->|Low| M
M --> P[Log approved transaction]
P --> Q[Return 200 OK]
Frequently asked questions
- What is a risk score and how does it prevent fraud?
- A risk score quantifies the likelihood a transaction is fraudulent based on signals: is the user's location plausible? have they made similar transactions before? is the amount typical? Combine signals into a score (0–100). Transactions above a threshold get blocked, middle scores get challenged with 2FA, low scores proceed instantly. This balances security (stop fraud) with user experience (don't block legitimate users).
- What are velocity rules and why do they detect fraud?
- Fraudsters test stolen cards rapidly (many small charges in minutes). Velocity rules limit how many transactions a card/IP/user can attempt in a time window (e.g., max 5 transactions in 5 minutes). Exceed the limit, block the transaction. Legitimate users rarely hit these limits; fraudsters hit them within seconds. Velocity rules catch attacks in real-time before they scale.
- What is impossible travel detection?
- A user in New York makes a purchase; 10 minutes later, their card is used in London. Physically impossible. Impossible travel flags this as high-risk because no one can travel that fast. Check the user's last known location and the time since the last transaction. If travel time is impossible given distance and speed, flag it. Real users moving between time zones are rare; fraudsters are common enough that this signal matters.
- Why request 2FA instead of just blocking?
- Blocking too aggressively drives users away (they get frustrated and switch to a competitor). Challenging with 2FA (SMS code, app push, email confirmation) lets legitimate users prove ownership while slowing down fraudsters (they don't have access to the user's phone). It's a speed bump, not a wall. Users who pass 2FA are almost certainly legitimate; those who can't are likely fraudsters.
Related templates
Role-based access control decision
Authorization logic: user roles, permissions, and resource access checks.
Secrets management and rotation
Credential storage, access, and automated rotation workflow.
Security access review workflow
Periodic user access audits with remediation and approval.