Fraud and Anomaly Detection Interview Questions 2026 (50 Questions)

Fraud detection interview questions in 2026 test whether you can catch rare, adaptive bad behaviour in real time without burying investigators in false alarms or blocking honest customers. This guide collects 50 high-value questions with model answers on anomaly types, rules versus statistical and machine learning methods, extreme class imbalance, label delay, velocity and graph features, real-time scoring, drift, fraud rings, explainability, review queues and the narrow role GenAI should play. It suits data scientists, ML engineers and data engineers preparing for fraud, transaction monitoring and AML ML interviews at banks, payment companies, insurers and the GCCs that serve them.

How to use this guide

Fraud interviews are rarely about one algorithm. Panels want to see that you understand the whole loop: data arrives, a score is produced in milliseconds, a decision is taken, a human may review it, a label arrives weeks later, and the model is retrained on a world that its own decisions have changed. What interviewers commonly probe at each level:

• Freshers: point, contextual and collective anomalies, isolation forest and LOF intuition, why accuracy is useless on imbalanced data, and precision versus recall.
• Mid-level engineers: sampling and cost-sensitive learning, threshold tuning against review capacity, velocity features, point-in-time correctness, label delay and chargebacks.
• Senior engineers and architects: real-time scoring architecture and latency budgets, champion-challenger rollout, drift versus adversarial adaptation, fraud ring detection with graphs, explainability for regulators, and feedback-loop bias.

General ML theory (bias-variance, regularisation, tree ensembles) is covered in our machine learning interview questions, so this page stays on what is specific to fraud and anomaly detection.

• Fundamentals: anomalies and detection methods (Q1–Q9)
• Supervised models, imbalance and metrics (Q10–Q17)
• Feature engineering for fraud (Q18–Q24)
• Real-time architecture, drift and adversaries (Q25–Q31)
• Graphs, rings and mule networks (Q32–Q34)
• Investigators, explainability, GenAI and fairness (Q35–Q40)
• Real-world scenario questions (Q41–Q50)
• Key takeaways
• Interview preparation checklist
• FAQ

Fundamentals: anomalies and detection methods

1. What is the difference between fraud detection and anomaly detection?

Answer: Anomaly detection finds data that is unusual relative to a learned notion of normal. Fraud detection finds behaviour that is intentionally deceptive and causes loss. The two overlap but are not the same: many anomalies are honest (a customer buying a sofa once, a salary credit on a new date), and much fraud is deliberately made to look normal (small test transactions, mule accounts that behave like students). Anomaly detection is useful when labels are scarce or the pattern is new; supervised fraud models win when you have reliable labels for known fraud types. Production systems combine both with rules and human review.

Interview tip: Say early that "unusual" and "fraudulent" are different targets. It signals that you will not ship an anomaly score as a fraud verdict.

2. Explain point, contextual and collective anomalies with payment examples.

Answer:

• Point anomaly: a single record is unusual on its own, such as a card transaction many times larger than anything the customer has ever spent.
• Contextual anomaly: a record is unusual only in its context (time, place, customer segment). A large electronics purchase is normal during a festival sale but odd at 3 a.m. from a new device for a pensioner who usually pays utility bills.
• Collective anomaly: each record looks fine, but a group is unusual together, such as many small transfers from different accounts landing in one new account within minutes, or a sequence of password reset, new device registration and beneficiary addition followed by a transfer.

Each type needs different tooling: point anomalies suit simple statistical or isolation methods, contextual anomalies need features or models conditioned on context, and collective anomalies need sequence models, windowed aggregates or graph analysis.

3. Why do fraud teams still use rules, and where do rules break down?

Answer: Rules are fast to deploy, easy to explain to auditors and investigators, deterministic, and often required for policy (sanctions hits, blocked merchant categories, known compromised cards). When a new attack appears on a Friday evening, a rule can be live in an hour while a retrained model takes days. Rules break down because they are brittle (fraudsters learn the threshold and stay just under it), they interact in ways nobody tracks, they accumulate over years until no one knows which still fire usefully, and they cannot weigh hundreds of weak signals together. The mature pattern is layered: hard policy rules, an ML risk score, and a small set of tactical rules with owners and expiry dates.

Real-world example: Consider a bank with several hundred legacy rules. A rule audit that measures each rule's hit rate, precision and overlap with the model score usually shows that a large share can be retired, which frees investigator time without increasing losses.

4. What statistical methods would you use as a baseline anomaly detector?

Answer: Start with per-entity baselines: z-scores or, more robustly, median and median absolute deviation (MAD) of amount per customer, because fraud data is heavy-tailed and means are distorted by outliers. Add percentile thresholds per segment, control charts for aggregate rates (declines per merchant per hour), and seasonal baselines for time-dependent metrics. For multivariate data, Mahalanobis distance captures correlated features but assumes roughly elliptical data. These baselines are cheap, explainable and make excellent features for later ML models, so they are rarely wasted work.

Interview tip: Mention that seasonal baselines come from time-series practice; our time-series forecasting interview questions cover decomposition and anomaly bands in more depth.

5. How does isolation forest work, and why is it popular for fraud?

Answer: Isolation forest builds many random trees, each splitting on a random feature at a random value between its minimum and maximum. Anomalies are few and different, so they get isolated in fewer splits; the anomaly score is based on the average path length across trees, normalised by the expected path length for the sample size. It is popular because it is fast, scales to large data with subsampling, needs no labels and no distance metric, and handles many features reasonably. Weaknesses: it struggles with anomalies that are only unusual in a combination of features aligned against the axes, it is sensitive to irrelevant features that dilute splits, and the contamination parameter is a guess that you should replace with a threshold chosen from review capacity.

6. Explain Local Outlier Factor (LOF). When does it beat isolation forest?

Answer: LOF compares the local density around a point with the density around its k nearest neighbours. A score near one means the point is as dense as its neighbourhood; a much higher score means it sits in a sparser region than its neighbours, so it is a local outlier. It beats isolation forest when data has clusters of very different densities: a transaction can be far from a tight cluster of salaried customers yet close to a looser cluster of small traders, and a global method misjudges it. Costs: it needs a meaningful distance (so feature scaling and encoding matter a lot), nearest-neighbour search is expensive at scale, and the classic version is transductive, so you need the novelty-detection mode or an approximate nearest-neighbour index to score new points online.

7. How do autoencoders detect anomalies, and what are the pitfalls?

Answer: An autoencoder is trained to compress and reconstruct normal data. At scoring time, a high reconstruction error means the input does not look like what the model learned, so it is flagged. Variants include sequence autoencoders for session or transaction sequences and variational autoencoders that give a probabilistic score. Pitfalls: if the training data contains fraud, the model learns to reconstruct it too; a powerful network can reconstruct anomalies well (it generalises too much); reconstruction error is dominated by high-variance features unless you weight or normalise them; and the score is hard to explain. Per-feature reconstruction error helps investigators see which fields were unusual.

8. What are one-class models, and how do you choose the threshold without labels?

Answer: One-class models learn a boundary around normal data: one-class SVM finds a boundary in a kernel space with the nu parameter bounding the fraction of training points treated as outliers, and Deep SVDD learns a representation that maps normal data close to a centre. Without labels you choose the threshold operationally: decide how many alerts the review team can handle per day, set the threshold so the expected alert volume matches, then collect investigator outcomes on those alerts and a small random sample below the threshold. Those outcomes become your first labels, which lets you measure precision and eventually move to a supervised or semi-supervised model.

9. When would you choose unsupervised, semi-supervised or supervised approaches?

Answer:

Approach	Use when	Main risk
Unsupervised (isolation forest, LOF, autoencoder)	New product, no labels, or hunting unknown patterns	Flags unusual-but-honest behaviour; low precision
Semi-supervised (trained on clean normal data, or few labels plus many unlabelled)	Some confirmed cases, many unknowns	"Normal" training set is contaminated with unlabelled fraud
Supervised (gradient boosting, neural nets)	Reliable labels for known fraud types	Blind to patterns absent from the labels; label delay and bias

In practice the supervised model carries most of the volume, and an anomaly model runs alongside it to surface new patterns for analysts, who turn confirmed cases into labels and rules.

Supervised models, imbalance and metrics

10. Fraud is extremely rare. Why is accuracy useless, and what do you report instead?

Answer: When fraud is a tiny fraction of transactions, a model that predicts "not fraud" for everything has near-perfect accuracy and catches nothing. Report metrics tied to the decision: precision and recall at the operating threshold, precision at k (where k is the daily review capacity), recall of fraud value (rupees caught, not just counts), false positive rate expressed as honest customers inconvenienced, PR-AUC for comparing models across thresholds, and an expected-cost figure that combines fraud loss, friction and review cost. Always slice by channel, product and segment, because a global number hides a model that fails on one channel.

11. Compare undersampling, oversampling and SMOTE for fraud data.

Answer: Undersampling the majority class shrinks training data, speeds up training and is the most common choice for large transaction tables; you lose some information about normal behaviour, so sample within time and segment strata. Random oversampling duplicates fraud cases and can overfit to them. SMOTE creates synthetic minority points by interpolating between neighbours; it can help on small tabular data but often creates unrealistic points in fraud, where features like device IDs, timestamps and categorical codes do not interpolate meaningfully, and it blurs the boundary with honest customers. For gradient-boosted trees on large data, modest undersampling or class weights usually work as well as or better than synthetic methods. Whatever you do, sample only the training set, never validation or test, and validate on a later time period.

12. If you undersample negatives for training, what happens to the predicted probabilities, and how do you fix it?

Answer: The model sees fraud more often than in reality, so its probabilities are inflated. If you kept a fraction r of negatives, the true odds equal the sampled odds multiplied by r, so the corrected probability is p = p_s * r / (p_s * r + 1 - p_s), where p_s is the model output. Alternatively, recalibrate on an unsampled, time-later validation set with isotonic regression or Platt scaling. Calibration matters because downstream systems use the score as a probability: expected-loss calculations, step-up authentication thresholds and capacity planning all break if a score of 0.3 does not mean roughly a three-in-ten chance.

13. What is cost-sensitive learning, and how would you set the costs?

Answer: Cost-sensitive learning makes errors cost different amounts during training (class weights or per-example weights) or at decision time (choosing the threshold that minimises expected cost). In fraud the costs are asymmetric and transaction-specific: a missed fraud costs roughly the transaction value plus recovery and handling cost, while a false positive costs review time, customer friction, possible churn and lost merchant revenue. I prefer to keep training close to standard log loss with modest weights, produce a calibrated probability, and then apply decision logic of the form "block if p * amount exceeds the cost of friction for this customer and channel". That keeps the business trade-off visible and adjustable without retraining.

Interview tip: Ask who owns the cost numbers. Fraud operations, product and finance usually disagree, and naming that tension shows you have worked with real stakeholders.

14. How do you tune the decision threshold for a fraud model?

Answer: Not with 0.5 and not once. Use a time-later validation set and plot precision, recall, alert volume and expected cost against the threshold. Then set thresholds per action, because fraud systems rarely have a single decision: a high band auto-declines or holds, a middle band triggers step-up authentication (OTP, in-app confirmation), another band sends to a review queue, and the rest pass. The review band is sized to investigator capacity, the decline band to an acceptable false positive rate, and step-up to customer friction tolerance. Re-check thresholds after every model release and during known seasonal peaks, since the score distribution shifts.

15. Why is PR-AUC preferred over ROC-AUC for fraud, and what is precision at k?

Answer: ROC-AUC plots true positive rate against false positive rate. With a huge number of honest transactions, a tiny false positive rate still means a flood of false alerts, but the ROC curve barely moves, so two models with similar ROC-AUC can produce very different alert queues. The precision-recall curve puts precision on an axis, so it shows directly how many alerts are real fraud. PR-AUC is therefore the better summary for comparing models on imbalanced data. Precision at k measures the fraction of true fraud among the top k scored items, where k matches what the team can review in a day or shift; it is the metric investigators feel, and it is often more useful than any area-under-curve number.

16. What is a cost curve, and how would you use it to compare two models?

Answer: A cost curve shows the expected cost of a classifier across a range of operating conditions, such as different ratios of false negative to false positive cost or different fraud prevalence. Instead of asking "which model has the higher AUC", you ask "for the cost ratios and volumes we actually face, which model costs less, and over what range". One model may win when fraud is expensive relative to friction (card-not-present high-value goods), another when friction dominates (low-value instant payments). In practice I compute expected cost per thousand transactions at candidate thresholds using real amounts and agreed cost assumptions, and present the comparison to fraud operations and finance together.

17. What is label delay, and how do chargebacks complicate model training?

Answer: Label delay is the gap between a transaction and the moment you know it was fraud. Card fraud is often confirmed through chargebacks or customer disputes that arrive weeks later; some fraud is never reported. Consequences: the most recent data looks cleaner than it is (immature labels), so training on it teaches the model that recent fraud patterns are legitimate, and evaluation on recent data overstates precision. Handling it:

• Define a label maturity window and train only on transactions older than it, using a gap between training and validation periods.
• Use faster partial labels (customer reports, investigator outcomes, blocked-card confirmations) for monitoring, with a separate mature-label evaluation later.
• Distinguish chargeback reasons: "fraud" chargebacks versus "item not received" or friendly fraud (a genuine cardholder disputing their own purchase), which need different models and policies.
• Track label arrival curves so you know what fraction of eventual fraud is visible after a given number of days.

Feature engineering for fraud

18. What are velocity features, and how do you design them?

Answer: Velocity features measure how fast and how much activity happens per entity over time windows: count and sum of transactions per card in the last few minutes, hour and day; distinct merchants or beneficiaries per account today; failed PIN or OTP attempts in the last hour; time since last transaction; and ratios of the current amount to the entity's rolling average. Design them per entity type (card, account, device, IP, beneficiary, merchant) and per window, include both short and long windows so the model can compare "now" with "usual", and use distinct counts, not just counts, because fraudsters spread across beneficiaries. Keep the set focused: hundreds of near-duplicate windows add latency and storage without much signal.

19. How do you compute velocity features in real time with low latency?

Answer: Compute them in a stream processor (for example Flink or Kafka Streams consuming the transaction topic) that maintains windowed aggregates per key and writes the latest values to a low-latency online store (an in-memory key-value store or a managed feature store). At scoring time the service reads precomputed aggregates and adds the current transaction itself, so the feature includes the event being scored. Practical details: use sliding or hopping windows with bucketed counters rather than storing every event; handle late and out-of-order events with event-time processing and watermarks; make updates idempotent so retries do not double count; and compute the same definitions in batch for training. Our Kafka interview questions cover partitioning and exactly-once semantics, which matter here.

20. What is point-in-time correctness, and why is it critical for fraud features?

Answer: Point-in-time correctness means every training row uses feature values exactly as they were known at the moment of the transaction, not values computed later. Fraud data is full of leakage traps: an account status that was set to "blocked" because of this fraud, a device risk score updated after the incident, a customer's "number of disputes" that includes this dispute, or aggregates computed over a whole day that include later transactions. A leaked model looks excellent offline and fails in production. Prevent it with event-time joins against feature history (as-of joins), a feature store that logs values served at scoring time, and the habit of training on logged online features where possible.

21. Which device, IP and session signals are useful, and what are their limits?

Answer: Useful signals include device identifier and age (how long this device has been seen for this customer), number of accounts linked to one device, emulator or rooted-device indicators, app integrity checks, IP reputation, whether the IP belongs to a hosting provider or anonymising proxy, distance and plausibility between IP location and usual location, SIM change recency for mobile banking, and behavioural signals such as typing cadence or navigation speed. Limits: device fingerprints can be spoofed or reset; carrier-grade NAT means many honest users share an IP; VPN use is common among honest users; and behavioural biometrics raise consent and privacy questions. Treat each as one signal among many, and check data protection obligations before collecting it; our privacy engineering interview questions cover purpose limitation and minimisation.

22. What graph features would you add to a transaction model?

Answer: Build a graph of entities (accounts, cards, devices, phone numbers, emails, IPs, beneficiaries, merchants) connected by shared use or money flow, then derive features such as: degree of the device or beneficiary (how many accounts touch it), number of hops to a known fraud or mule account, fraction of neighbours with confirmed fraud, connected component size and how fast it grew recently, PageRank or other centrality in the money-flow graph, and community labels from Louvain or Leiden. Compute heavy features in batch and store them per entity; compute simple ones (shared device count) incrementally. Respect point-in-time rules here too: "neighbour is a known fraudster" must use labels known at transaction time.

23. How do you build customer behaviour profiles without creating a huge feature table?

Answer: Keep a compact profile per entity updated incrementally: rolling statistics (exponentially weighted mean and variance of amount), typical hours and days, usual channels, top merchant categories and beneficiaries, home location area, and device set. Score the current transaction against the profile with deviation features ("amount relative to usual", "new beneficiary", "first transaction at this hour"). Exponentially weighted statistics need only a few numbers per entity and adapt naturally. For new customers with thin history, fall back to segment-level profiles and features that do not depend on history, and accept that new-customer fraud often needs its own model or rules.

24. How do you handle high-cardinality categorical features like merchant ID or beneficiary?

Answer: Options include target encoding with out-of-fold computation and smoothing (to avoid leaking the label), frequency encoding, hashing, learned embeddings in neural models, and native categorical handling in gradient boosting libraries. For fraud, target encoding must be time-aware: a merchant's fraud rate must be computed only from earlier, matured labels, otherwise it leaks. Rare and new categories need a sensible default (the segment rate) and a "newness" feature, since a brand-new beneficiary or merchant is itself a risk signal.

Real-time architecture, drift and adversaries

25. Design a real-time fraud scoring system for card or UPI payments.

Answer: The scoring path sits inside the payment authorisation, so it must be fast, available and safe on failure.

Payment request
     |
     v
Scoring API ---> Online features (velocity,
     |            profile, device, graph)
     v
Policy rules ---> ML model (in-process)
     |
     v
Decision: allow | step-up | review | block
     |
     +--> Event log (Kafka) --> Feature
     |                           pipelines
     v
Case queue --> Investigators --> Labels
                                   |
                     Training <----+

Key design choices: features are precomputed by streaming jobs so the request path only does reads; the model runs in-process (a compiled tree ensemble or exported model) to avoid a network hop; every request, feature vector, score, model version and decision is logged for audit and training; there is a timeout with a defined fallback (rules-only decision) when the model or feature store is slow; and the case management system feeds investigator outcomes back as labels. Batch jobs compute graph features and retrain models; a champion-challenger setup scores traffic in shadow before promotion.

26. How would you split a latency budget for real-time scoring?

Answer: Start from the payment network's or product's end-to-end budget, then allocate it explicitly: request parsing and enrichment, feature reads, model inference, rules evaluation, decision logging, and network overhead, with headroom for tail latency. Design for the p99, not the average, because authorisation timeouts are what customers feel. Techniques: batch all feature reads into one round trip, keep the online store in the same region and zone, avoid synchronous calls to external enrichment services (precompute or cache them), keep the model small enough for in-process inference, write logs asynchronously, and load test with production-like key distributions so hot keys are exposed. Define what happens on timeout before you go live.

Interview tip: Never quote a latency number as universal. Say "the budget is set by the scheme or product; here is how I would split whatever we are given".

27. What should happen when the fraud model or feature store fails?

Answer: Decide fail-open versus fail-closed per channel and risk band in advance, with the business. Failing closed (declining everything) is safe against fraud but damages customers and revenue; failing open (approving everything) invites attacks if fraudsters notice the outage. The usual compromise is a degraded mode: hard policy rules still run, a lightweight fallback model or rule set using only request fields scores the payment, high-value or high-risk transactions go to step-up or hold, and alerts fire to on-call. Test the fallback regularly with chaos-style drills and track the share of decisions taken in degraded mode.

28. How do you roll out a new fraud model safely?

Answer: Offline validation on a time-later, mature-labelled period first, then shadow mode where the challenger scores live traffic without affecting decisions, so you can compare score distributions, alert volumes and latency. Next, a limited live rollout on a slice of traffic or a single channel with clear rollback criteria, then progressive expansion. Classic A/B testing is awkward because labels arrive late and fraudsters may notice the weaker arm, so combine champion-challenger with careful power analysis; our A/B testing interview questions cover the statistics. Always version the model, features and thresholds together, and get sign-off from model risk where the bank has a model governance process.

29. What kinds of drift affect fraud models, and how do you monitor them?

Answer: Data drift (feature distributions change, for example a new payment app version changes device fields), prior drift (fraud rate changes during an attack or season), and concept drift (the relationship between features and fraud changes, for example a feature that once signalled fraud becomes normal). Monitor input distributions with population stability or divergence measures per feature and segment, score distributions and alert volumes daily, early-label precision from investigator outcomes, and mature-label recall and precision as labels arrive. Because labels are delayed, input and score monitoring are your early warning; label-based metrics confirm later. Pipeline bugs cause many apparent drifts, so check data quality before blaming the world. The MLOps interview questions cover monitoring stacks in general.

30. How is adversarial adaptation different from ordinary concept drift?

Answer: Ordinary drift is indifferent to your model; adversarial adaptation responds to it. Fraudsters probe thresholds with small test transactions, move to channels or segments where controls are weaker, mimic the features of good customers, and change tactics once a rule is known. Implications: the model's success creates its own decay; public or leaked thresholds are exploited quickly; feature importance can tell attackers what to fake. Countermeasures include features that are expensive to fake (account age, long-term behaviour, graph position), randomised elements in step-up decisions, keeping rule thresholds confidential, fast-response tactical rules, frequent retraining, anomaly detectors alongside supervised models to catch new tactics, and red-team exercises in which analysts try to beat the model.

31. How do the system's own decisions bias the training data, and what can you do about it?

Answer: Blocked transactions never complete, so you never learn whether they were really fraud; only reviewed alerts get investigator labels; and transactions below the threshold are assumed good until a dispute arrives. Retraining on this data teaches the model to confirm its own past decisions (selective labels and feedback loops). Mitigations: hold out a small, carefully approved random sample of low- and mid-risk alerts for review regardless of score, log the score and decision for every transaction, use the investigator outcomes of step-up challenges (passed or failed) as partial labels, apply inverse propensity weighting where you know the probability of review, and evaluate new models against these unbiased samples rather than only against past alerts.

Graphs, rings and mule networks

32. How do you detect fraud rings that a per-transaction model misses?

Answer: A ring is a set of accounts or identities cooperating, often sharing devices, phone numbers, addresses, IPs or beneficiaries, so each member looks moderately normal on its own. Build an entity graph, then look for structures: unusually large or fast-growing connected components, dense communities with many shared attributes, star patterns where many accounts pay one beneficiary, chains and cycles of money movement, and synthetic identities that share pieces of real identities. Use community detection and similarity measures to surface candidate rings, score each community (shared attributes, fraud history among members, growth speed), and present the whole cluster to investigators, who can act on it together. Our knowledge graph interview questions cover graph modelling, entity resolution and supernode handling in depth.

33. When are graph neural networks worth it for fraud, and what are the risks?

Answer: Graph neural networks learn from both node features and neighbourhood structure, so they can capture patterns like "a new account connected through two hops to confirmed mules" without hand-written features. They are worth trying when relational signal is strong and hand-crafted graph features have plateaued. Risks: training and serving complexity (neighbourhood sampling, keeping embeddings fresh), label leakage through neighbours, difficulty explaining a score to investigators and regulators, and camouflage, where fraudsters connect to many good nodes to dilute their neighbourhood. A common compromise is to compute graph embeddings in batch, store them as features in a gradient boosted model, and keep explainable graph features alongside them.

34. How do entity resolution mistakes affect fraud graphs?

Answer: If you wrongly merge two different people (same name, same city), you link an innocent customer to a fraud network and may freeze their account. If you fail to merge records that belong to one fraudster (slightly different spellings, new phone numbers), the ring stays fragmented and invisible. Treat entity resolution as a risk-bearing model: prefer strong identifiers, keep source records and merge provenance, make merges reversible, measure precision and recall of matching on a labelled sample, and never let a fuzzy match alone trigger an adverse action. Shared attributes that are common for honest reasons (a hostel address, a corporate Wi-Fi IP, a family phone) need allowlists or down-weighting.

Investigators, explainability, GenAI and fairness

35. How do you explain fraud scores to investigators and to regulators?

Answer: The two audiences need different things. Investigators need fast, case-level reasons: the top contributing factors in plain words ("new device first seen today", "beneficiary added ten minutes before transfer", "amount far above usual"), the relevant history, and links to related entities. Use SHAP or similar attributions translated into reason codes, and show raw facts alongside them so investigators can verify. Regulators, auditors and model risk teams need the system-level story: model purpose, data sources, features and why they are justified, validation results by segment, monitoring, override rates, and the governance around changes. Keep attributions stable across releases where possible, and test that reason codes are faithful (removing the top factor should materially change the score).

Interview tip: Say that explanation is also a debugging tool. Odd reason codes are often the first sign of a leaky or broken feature.

36. How would you design human review queues and the feedback loop?

Answer: Order the queue by expected value (probability multiplied by amount at risk, adjusted for time sensitivity), not by raw score, so high-value, time-critical cases are handled first; real-time holds need a short service level, while post-event AML alerts can wait longer. Group related alerts into one case (same customer, same ring) to avoid duplicate work. Capture structured outcomes (confirmed fraud with type, false positive with reason, unable to determine) rather than free-text notes, because those outcomes become labels and rule feedback. Track per-reviewer agreement and turnaround, rotate difficult queues, and sample closed cases for quality assurance. Our article on human-in-the-loop AI covers review design patterns that transfer directly.

37. What is transaction monitoring in AML, and how does ML fit into it?

Answer: Anti-money laundering (AML) transaction monitoring looks for patterns that suggest laundering or terrorist financing, such as structuring (splitting amounts to stay under reporting thresholds), rapid movement of funds in and out, layering through many accounts, activity inconsistent with the customer's declared profile, and links to high-risk counterparties. It differs from payment fraud: the "victim" is often the financial system, alerts are usually reviewed after the fact, and outcomes include regulatory reports (in India, suspicious transaction reports filed with FIU-IND). Traditional systems are rule-heavy and produce many false alerts. ML commonly helps by prioritising or scoring rule alerts, segmenting customers so thresholds fit each segment, detecting network patterns with graphs, and surfacing unusual behaviour for analysts. Because regulators expect explainable, documented coverage, ML usually augments rules rather than replacing them, and every model change goes through validation and governance.

38. What role should GenAI play in fraud and AML operations?

Answer: GenAI is useful around the decision, not as the decision. Good uses: drafting case summaries and suspicious activity narratives from structured case data for an investigator to edit and approve, an investigator copilot that answers questions about a case using retrieval over the customer's transactions, prior cases and internal procedures with citations, summarising long customer communication threads, and helping analysts write queries against case data. Poor uses: letting an LLM decide whether to block a payment, file a report or close a case, or letting it generate facts that are not in the evidence. Controls include grounding only on case data, citations for every claim, field-level validation of amounts and dates against source systems, a named human approver, logging of prompts and outputs, and PII protection. See our guide to generative AI in banking for how banks scope these use cases by risk.

39. How does fraud detection differ for UPI and real-time payments in India?

Answer: UPI payments are instant, available around the clock, often low in value and very high in volume, and once money moves it is hard to recover, so the window to stop fraud is the authorisation itself. Much UPI fraud involves social engineering rather than stolen credentials: the genuine customer is tricked into approving a collect request, scanning a QR code or sharing a PIN, so the transaction looks authenticated. Useful signals therefore include first-time payee, payee account age and inbound pattern (mule indicators), collect requests from unknown handles, device and SIM changes, unusual time and amount for the customer, and screen-sharing or remote-access app signals where available and permitted. The ecosystem involves the payer's bank, the payee's bank, the payment app and the network operator, so data and responsibilities are split; know which signals your institution actually sees. Regulatory expectations from the RBI and NPCI evolve, so check current guidelines rather than quoting rules from memory.

40. How do you test a fraud model for fairness?

Answer: Fraud models can impose unequal burdens: more declines, holds or step-up challenges for certain regions, age groups, languages or income segments, often through proxies such as location, device type or transaction patterns of informal workers. Measure false positive rates and friction rates (declines, holds, challenges, account freezes) by relevant segment, alongside detection rates, since honest customers pay the cost of false positives. Investigate large gaps: is it a real difference in fraud exposure or a proxy effect? Mitigations include removing or constraining proxy features, segment-aware thresholds where justified and documented, better features for thin-file customers, and making step-up (a challenge) rather than outright decline the default for uncertain cases. Document the analysis for model risk review. Our guide to AI bias and fairness testing walks through metrics and test design.

If you want to build these skills hands-on, from imbalanced classification and feature pipelines to cloud deployment and security controls, Cloudsoft's APEX AI, ML, Cloud and Cyber Security program covers ML engineering alongside cloud and security foundations.

Real-world scenario questions

41. Precision dropped sharply during a festival sale, and investigators are flooded with false alerts. What do you do?

Answer: Festival sales change honest behaviour: larger baskets, more first-time merchants, late-night shopping, new devices, gift deliveries to other addresses and spikes from customers who rarely shop online. Those look like the deviation features the model was trained to fear, so scores shift up and alert volume explodes while fraud may rise only modestly. Short term, protect the customer experience and the queue; longer term, teach the model about seasonality.

What I would check:

1. Score and alert volume by channel, merchant category and segment, to see whether the shift is broad or concentrated in a few large merchants.
2. Which features moved most (amount ratios, new-merchant flags, time-of-day) and whether any pipeline issue is involved.
3. Early investigator outcomes on a sample of new alerts, split by score band, to estimate real precision.
4. Whether fraud actually rose (attackers like sale periods too), especially in high-value electronics and gift cards.
5. Whether previous festival periods are in the training data and what the model did then.

Production consideration: Temporarily raise the review threshold or route the middle band to step-up authentication instead of the review queue, with fraud operations' sign-off and a defined end date. For the future, add calendar and campaign features, use segment-relative baselines that adapt (exponentially weighted profiles), include past festival periods in training and validation, and run a pre-season readiness review with merchants' campaign calendars.

42. Analysts discover a new fraud pattern that the model completely missed for weeks. How do you respond?

Answer: Contain, understand, then close the gap at several layers. A supervised model cannot recognise a pattern absent from its labels, so the miss is not surprising; what matters is how fast the system adapts.

What I would check:

1. The confirmed cases: what they share (channel, merchant, device type, beneficiary, sequence of actions) and how the attack works end to end.
2. Whether any existing feature or anomaly score showed the pattern, and why it did not cross thresholds.
3. How many similar transactions exist in history, by searching for the pattern retrospectively, and which are still recoverable.
4. Whether data that would reveal the pattern is missing from the feature pipeline altogether.
5. Whether anomaly detectors flagged it and alerts were ignored or deprioritised.

Production consideration: Deploy a tactical rule with an owner and expiry date immediately, label the historical cases, add features that capture the mechanism, retrain and validate, then retire the rule if the model covers it. Fix the process too: give unsupervised alerts a dedicated analyst review slot, and run regular pattern-hunting sessions so detection of new tactics does not depend on customer complaints.

43. Investigators say the queue has so many false positives that real fraud is buried. How do you fix it?

Answer: Treat it as a capacity and prioritisation problem, not only a model problem. Measure the queue: alert sources (which rules and models create them), precision per source, duplicates, and how long cases wait.

What I would check:

1. Precision and volume per rule and per model band; usually a few noisy rules generate much of the volume.
2. Overlap: alerts raised by several rules for the same customer or event, which should be grouped into one case.
3. Whether the queue is ordered by expected value or by arrival time.
4. Whether investigator outcomes are fed back into training and rule tuning at all.
5. Whether some alert types could be handled by customer self-confirmation (in-app "was this you?") instead of human review.

Production consideration: Retire or tighten low-precision rules after checking their unique catches, merge related alerts into cases, sort by expected loss, add a model that scores rule alerts using past outcomes, and set precision at k targets that match daily capacity. Report caught fraud value per investigator hour so the improvement is visible to management. A GenAI case summary can reduce handling time, but it does not fix a bad queue.

44. Design an approach to detect mule accounts.

Answer: Mule accounts receive and quickly forward proceeds of fraud, sometimes knowingly, sometimes recruited with "work from home" offers. They are often new or dormant accounts that suddenly receive many inbound credits from unrelated senders and pass the money on within minutes or hours, frequently via cash withdrawal or onward transfers, leaving little balance.

What I would check:

1. Inbound patterns: number of distinct senders, share of inbound from first-time senders, links of those senders to reported fraud victims.
2. Pass-through behaviour: time between credit and debit, ratio of outflow to inflow, residual balance.
3. Profile mismatch: activity inconsistent with declared occupation or income, dormant account reactivated.
4. Shared device, phone, IP or KYC attributes with other accounts, and position in the money-flow graph.
5. Onboarding signals: recent opening, digital onboarding anomalies, change of mobile number after opening.

Production consideration: Combine an account-level model (scored daily and on each inbound credit) with graph analysis that follows money from confirmed victims, so one confirmed fraud reveals several mule hops. Actions must be proportionate and reviewed: enhanced monitoring, holds on outbound transfers pending review, or account restriction, following the bank's policy and regulatory process. Some account holders are themselves victims of recruitment scams, which matters for how cases are handled.

45. Your new model shows excellent offline results but performs much worse in production. What went wrong?

Answer: The usual suspects are leakage and training-serving skew.

What I would check:

1. Point-in-time correctness: features using information that only existed after the transaction (account status, dispute counts, day-level aggregates).
2. Training-serving skew: the same feature computed differently in batch and streaming (time zones, window boundaries, missing-value defaults).
3. Validation design: random splits instead of time-based splits, or validation on immature labels.
4. Population differences: offline data from one channel or period that does not match live traffic.
5. Thresholds tuned on sampled data with uncorrected probabilities.

Production consideration: Log served feature vectors and compare them with offline values for the same transactions; this single check finds most skew bugs. Train future models on logged online features where possible, and keep a time gap between training and validation data equal to the label maturity window.

46. A customer complains that their legitimate payments keep getting declined, and the case reaches senior management. How do you handle it?

Answer: Resolve the individual case quickly and use it to find a systemic issue.

What I would check:

1. The logged decisions for this customer: scores, reason codes, rules fired and model versions.
2. Whether a single feature drives the declines (for example a device flagged as shared because of a family phone, or a location mismatch from travel).
3. How many other customers share that pattern, and the false positive rate for that segment.
4. Whether the customer has passed step-up challenges before, a strong signal that should lower future friction.

Production consideration: Give operations a controlled way to whitelist or adjust a customer with audit trail and expiry, feed "passed challenge" and "confirmed genuine" outcomes back as features and labels, and add segment-level friction monitoring so similar issues are caught before customers escalate. Explain the decision to the customer in plain terms without revealing thresholds.

47. Fraud losses rise after you tighten a rule. Why might that happen?

Answer: Tightening one control can push fraudsters elsewhere (displacement) or overload a downstream process.

What I would check:

1. Whether fraud moved to another channel, product or amount band just under the new threshold.
2. Whether the extra alerts overloaded the review queue, so real fraud waited too long and completed.
3. Whether the change interacted with other rules or the model in unexpected ways.
4. Whether the timing coincides with a separate attack unrelated to the rule.

Production consideration: Evaluate controls at the portfolio level, not one rule at a time. Before changes, simulate impact on alert volume and capacity; after changes, monitor neighbouring channels and amount bands. This is adversarial adaptation in action, so expect it.

48. The business wants the GenAI copilot to automatically close low-risk AML alerts. How do you respond?

Answer: I would push back on the framing and offer a safer path. Closing an alert is a regulatory decision with audit consequences; an LLM's judgement is hard to validate, can be inconsistent, and can be manipulated through text in the case data. A better design keeps the decision in a validated, explainable scoring model and a human.

What I would check:

1. Whether a conventional model trained on past alert outcomes can identify low-risk alerts with measurable, validated precision.
2. What the compliance and model risk teams and the regulator's expectations allow for automated alert handling.
3. How much time investigators actually spend on low-risk alerts, and whether summarisation alone removes most of it.
4. How decisions would be audited, sampled and reversed.

Production consideration: Use the copilot to pre-fill a summary and a recommended disposition with cited evidence, let a validated model prioritise, and keep a named analyst approving closures, with quality assurance sampling of closed alerts. Any move towards automation goes through model governance with documented validation, not a product decision.

49. A wave of account takeover attacks follows a data breach at another company. What changes?

Answer: Leaked credentials lead to credential stuffing and account takeover; the fraud shows up first at login and profile change, before any payment.

What I would check:

1. Login failure rates, logins from new devices and IPs, and logins from hosting providers or anonymising proxies.
2. Sequences after login: password or mobile number change, new beneficiary, then transfer.
3. Whether session-level and event-sequence features are available to the payment model at all.
4. Which customers had accounts that may appear in the breach, if that information is available and lawful to use.

Production consideration: Score the session, not only the payment: add login and profile-change risk, cooling-off periods for new beneficiaries after sensitive changes, step-up on risky sessions, and rate limits at the edge. This is a collective anomaly problem, so sequence features and short-window velocity on login events matter more than per-payment amount features.

50. You are asked to build a fraud system for a new digital lending product with no fraud labels. Where do you start?

Answer: Start with the threat model and controls, not a model. List likely fraud types (synthetic identities, first-party fraud with no intent to repay, document tampering, loan stacking, mule disbursement accounts) and the data available at each stage of the journey.

What I would check:

1. Identity and KYC verification signals, document checks and bureau data available at onboarding.
2. Device, IP and application-velocity signals (many applications from one device or address).
3. Patterns from related products in the same institution, which can provide transfer learning or initial rules.
4. How and when outcomes will be known (early payment default as a fraud proxy, confirmed identity fraud reports), and how long that takes.

Production consideration: Launch with policy rules, identity checks, velocity limits and an anomaly detector whose threshold matches review capacity, and route uncertain applications to manual review. Design label capture from day one (structured investigator outcomes, early-default flags with fraud confirmation), then train a supervised model once enough mature labels exist, while keeping the anomaly layer for new patterns.

Key takeaways

• Unusual is not the same as fraudulent: anomaly scores find candidates, supervised models and investigators confirm them.
• Under extreme imbalance, use precision at k, PR-AUC, value-weighted recall and expected cost, with thresholds set per action and sized to review capacity.
• Label delay, chargeback types and selective labels shape every training and evaluation decision; keep maturity windows and unbiased review samples.
• Velocity, profile, device and graph features carry most of the signal, and all of them must be point-in-time correct and identical in training and serving.
• Real-time scoring needs precomputed features, in-process inference, full decision logging and a tested degraded mode.
• Fraudsters adapt to your controls, so combine fast tactical rules, frequent retraining, anomaly detection and graph analysis of rings and mules.
• GenAI drafts narratives and supports investigators; validated models and named humans make the decisions, with fairness and explainability checked by segment.

Interview preparation checklist

• Train isolation forest, LOF and an autoencoder on a public transaction dataset and compare precision at k against a gradient boosted model.
• Practise deriving the probability correction for undersampled negatives and explaining calibration.
• Build a time-based validation split with a label maturity gap and show how a random split inflates results.
• Implement a few velocity features in a streaming tool and the same features in batch, then check they match.
• Draw the real-time scoring architecture from memory, including feature store, fallback path, logging and feedback loop.
• Build a small entity graph (accounts, devices, beneficiaries) and find suspicious components with community detection.
• Prepare one story each on a false positive problem, a missed pattern, and a stakeholder disagreement about costs or thresholds.
• Revise how GenAI fits into investigations with citations and human approval, and how you would test segment-level fairness.

FAQ

What skills are required for a fraud detection data scientist or ML engineer role?

You need strong SQL and Python, supervised learning with gradient boosted trees, anomaly detection methods, evaluation under class imbalance, feature engineering with time windows, and an understanding of payments or banking processes. Senior roles add streaming pipelines, real-time serving, model governance and graph analytics.

How should a fresher prepare for fraud detection interview questions?

Learn the fundamentals in this guide, then build one end-to-end project on a public fraud dataset: time-based split, imbalance handling, threshold tuning by review capacity, and a short write-up of costs and trade-offs. Be ready to explain why accuracy is misleading and how you chose your metric.

Which algorithms are most commonly used in fraud detection machine learning?

Gradient boosted tree ensembles are the common workhorse for supervised fraud models on tabular data. Isolation forest, LOF and autoencoders are common for anomaly detection, and graph methods are used for rings and mule networks. Rules remain part of almost every production system.

Are anomaly detection interview questions different from fraud detection questions?

They overlap. Anomaly detection questions focus on unsupervised methods, thresholds without labels and types of anomalies, and also appear in IT operations, manufacturing and security roles. Fraud questions add imbalance, label delay, adversaries, real-time decisions and regulation.

What is asked in a transaction monitoring or AML ML interview?

Expect questions on AML typologies such as structuring and layering, how rule-based monitoring works, how ML can prioritise or reduce false alerts, network analysis of related accounts, explainability for regulators, and how alerts move through investigation to reporting.

Do I need banking domain knowledge for a fraud analytics role?

It helps a lot. You should understand how cards, UPI, net banking and loans work, what a chargeback is, what KYC involves and how investigations are run. Many teams will teach product details, but basic payments knowledge makes your answers far more credible.

Is fraud detection a good career choice for ML engineers in India?

It can be a strong specialisation. Banks, payment companies, insurers, e-commerce firms and the GCCs in Hyderabad and Bengaluru that support global financial institutions all run fraud and risk teams, and the skills transfer well to security analytics, credit risk and AML.

Will GenAI replace fraud detection models?

No. Fraud decisions need fast, validated, explainable models on structured data. GenAI is useful for drafting case narratives, summarising evidence and assisting investigators, with a human approving the outcome.

Fraud systems reward engineers who can connect models, streaming data, cloud infrastructure and governance into one reliable loop. To build that combination, explore the APEX program at Cloudsoft, which pairs AI and ML engineering with cloud and cyber security. If you would rather take AI systems into customer environments end to end, from discovery to secure deployment and evaluation, the AI Forward Deployed Engineer FDE PRO program covers that path, including a secure banking AI assistant project, with placement support until you're placed. Classes run in Ameerpet, Hyderabad, or live online; call +91 96660 19191 for a free demo.

Related Cloudsoft resources

• Knowledge Graph Interview Questions 2026
• Machine Learning Interview Questions
• Time Series Forecasting Interview Questions
• Generative AI in Banking
• AI Bias and Fairness Testing
• MLOps Interview Questions
• Kafka Interview Questions