Fraud Detection and Risk Engine
Check every order, payment, login or signup in real time and give it a risk score: allow, challenge (OTP/CAPTCHA) or block.
61.1 Why is it used?
- Referral/coupon abuse through fake accounts. One person takes the first-order discount 500 times with 500 accounts.
- COD fraud: fake addresses or repeatedly refusing orders. The logistics money is lost (RTO cost).
- Payment fraud: an order with a stolen card, a chargeback comes in and the merchant has to return the money.
- Account takeover: logging in with a leaked password and using the wallet balance or a saved card.
- The decision is needed in milliseconds. If checkout gets slow, even genuine customers leave.
61.2 How it works
- 1.Users + bots: a 'first order Rs 200 off' coupon, signup/login/checkout events go into Kafka
- 2.Apache Flink: velocity counts, like 40 signups from one device in 1 hour; fetched in ms from the Redis / Feast feature store
- 3.Checkout API (new account, COD, a Rs 60K phone) -> Risk Engine, decision < 100 ms
- 4.The Risk Engine combines 4 signals: Rules (Drools), ML score (XGBoost), Device fingerprint (OS, screen, fonts, device ID), Graph (Neo4j: shared phone / address / UPI links)
- 5.Decision: Allow (low risk) / Step-up (OTP, 3DS, prepaid only) / Manual review (risk team queue) / Block (fraud ring, blacklist)
- 6.Feedback loop: chargeback + RTO real fraud labels -> weekly retraining -> a smarter model in the next sale
Example: same device > 5 accounts/day -> coupon ineligible; new account + COD + high-value = score 0.87 -> COD off, prepaid OK
- 1.300 accounts are linked to a single address (1 address)
- 2.Just 2 phone numbers (Phone A, Phone B) are shared across all the accounts
- 3.The whole ring is blocked at once
Run a new rule in shadow mode first: log only, do not block. Count false positives too, since blocking a genuine user is lost revenue. Keep it hybrid: rules = hard limits, ML = grey area
- Rules Engine: if-then rules like 'new account + order > 20,000 + COD = review'. Easy to understand, quick to change.
- ML Scoring: a model trained on past fraud data (XGBoost, random forest) gives each event a 0-1 risk score.
- Device Fingerprinting: a unique ID from browser/phone attributes (OS, screen, fonts, device ID). Catch 50 accounts on one device.
- Velocity Checks: how many times in a time window, like 5 failed payments from 1 card in 10 minutes or 30 signups from 1 IP.
- Real-time Features: compute rolling counts (orders per user in the last 1 hour) on Flink/Kafka streams and keep them in a feature store.
- Graph/Link Analysis: clusters of accounts linked by the same phone, address, device or UPI ID. Used to catch fraud rings.
- Decision: based on score + rules, Allow / Step-up (OTP, 3DS) / Manual Review / Block; the model is retrained from feedback (chargebacks).
- Shadow mode: log a new rule first, do not block. Enable it after checking false positives.
61.3 Tools you can use
| Tool | Type | How it is used |
|---|---|---|
| AWS Fraud Detector | Managed fraud ML service | Upload your own historical data; it trains a model and gives a fraud score and rule outcome through a real-time API. Verify availability in the AWS docs, since AWS has announced a wind-down for new customers. |
| Sift | SaaS fraud platform | Scores payment fraud, account takeover and fake accounts using global network data + ML; send events through the SDK. |
| Drools | Open-source rules engine (Java) | Write business rules in DRL files separate from the code, so the risk team can change rules without a deploy. |
| Apache Flink | Stream processing | Detect real-time velocity features (per user/card/IP counts) and CEP patterns from Kafka events. |
| Redis / Feature Store (Feast) | Low-latency feature store | Fetch precomputed features in ms and hand them to the model at scoring time. |
| Neo4j | Graph database | Model users, devices and addresses as nodes and find fraud rings through shared links. |
61.4 Comparison: Rules Engine (Drools) vs Managed ML (AWS Fraud Detector) vs SaaS (Sift)
| Point | Drools (rules) | AWS Fraud Detector | Sift |
|---|---|---|---|
| Approach | Hand-written if-then rules | ML model + rules on your data | ML on global network data + rules |
| Catching new fraud patterns | Only what a rule was written for | Yes, if it is in the training data | Also from other merchants' patterns |
| Explainability | Fully clear: which rule hit | Score + variable importance | Score + reason signals |
| Setup effort | You write the rules + infra | Data + model training in AWS | Integrate the SDK, go live quickly |
| Data control | Fully with you | In your own AWS account | Data goes to the vendor |
| Cost | Open-source, only infra | Pay per prediction | Subscription/volume based, expensive |
| Best for | Clear business policies, compliance rules | AWS shops that have labelled data | A fast start, a small risk team |
61.5 When to choose which
- Drools/rules engine: when the policy is clear (COD limit, blacklisted pincodes) and every decision must be explained.
- AWS Fraud Detector: you are on AWS, have labelled data of past fraud, and no ML team of your own.
- Sift: you want to go live quickly and need cross-merchant intelligence, and sending data outside is fine.
- Flink + feature store + your own model: big players (Amazon/Flipkart scale) who need full control and low latency.
- Best practice: hybrid. Rules for hard limits + ML score for the grey area.
61.6 Real-world example
Scenario: COD and coupon fraud on sale day.
- A 'Rs 200 off on first order' coupon goes live in the sale, and fraudsters create thousands of new accounts with bots.
- The signup event goes into Kafka; Flink counts: 40 signups from one device fingerprint in 1 hour.
- Rule hit: same device > 5 accounts/day -> mark the new accounts coupon ineligible.
- At checkout the ML model scores: new account, COD, high-value phone, high RTO rate for the pincode -> score 0.87.
- Decision: disable COD and show only the prepaid option (step-up). A genuine user pays prepaid and completes the order.
- Graph analysis finds 300 accounts linked to one address and 2 phone numbers: the whole ring is blocked.
- Chargeback and RTO data is fed into the weekly model retraining, so the model is smarter in the next sale.
61.7 Interview tips
- Ignoring false positives: overly strict rules block genuine customers, and the revenue loss can be bigger than the fraud.
- Batch-only (next day) analysis: fraud happens in real time, so you need a decision at checkout time.
- Hardcoding rules in code: every change needs a deploy, and the risk team slows down.
- Interview tip: be sure to cover rules vs ML, velocity checks, device fingerprinting and the feedback loop (chargeback labels). Quote the latency budget too: decision < 100 ms.