Fraud Detection System System Design Interview: Narrate It

The interviewer is not asking you to build a model. They are asking whether you can design a low-latency decision service in front of a slower learning loop, and defend where the human review step sits. In a fraud detection system system design interview, open with that framing, pin down the requirements, sketch two planes, then spend your time on latency and false positives. That order is what separates a strong answer from a tour of machine-learning buzzwords.

What is the interviewer testing in a fraud detection system design interview?

Three things get scored. Can you scope the requirement before drawing? Can you separate the real-time scoring path from the offline learning path? And can you say what a false positive costs versus a false negative?

The common trap is jumping straight to "train a model." Candidates who do that never define what a fraud decision costs in each direction, so every later trade-off is unanchored. A common follow-up is to let you run for two minutes, then ask why you chose a threshold — and the answer was never set up.

Say this sentence early: "I'll treat this as a low-latency decision service in front of a slower learning loop." It tells the interviewer you know the hard part is the decision path, not the training job, and it gives you a spine to hang every later choice on.

Which requirements should you pin down first?

Use four buckets, and ask about each in plain words.

• Callers. Who calls the system: payment authorization, login, account signup? Each has a different risk profile and a different tolerance for waiting.
• Decision returned. Allow, block, step-up challenge, or queue for review? Step-up is reversible; block is not.
• Latency budget. What is the p99 target per caller? A payment path and a signup path rarely share one.
• Data available. What features exist already, how fresh are they, and what labels come back later?

Ask verbatim: "Is the decision on the payment path, and what's the p99 budget — 100ms or a second?" Then: "What decisions can I return — can I step-up challenge, or is it binary allow/block?" And: "How late do chargeback labels arrive?"

The answers change the design. A 100ms payment path forbids synchronous feature lookups across many stores; you precompute and cache. A one-second signup path lets you do more work inline. If you can only return allow or block, your false-positive problem is much sharper, because you have no reversible middle option.

Scoping well is the same habit that carries other system design rounds. The reasoning in our consistency models walkthrough is a useful comparison for the next step: once you have stated a constraint like a p99 budget, you have to defend it against every later choice.

What does the architecture look like, and why split it in two?

Draw two planes and keep them apart.

The real-time decision plane handles event intake, feature lookup, rules plus model scoring, and the decision response. It must be fast and always available.

The learning plane handles the event log, label joins, model training, rule tuning, and deployment. It can be slow, batchy and occasionally down.

The event log is the spine. Every decision and its later outcome is written once and replayed by the learning plane. Name your stores by role, not brand: a low-latency feature store, a rules and config store, and a decision audit log.

Then say the sentence that signals seniority: "The real-time path must never depend on the training pipeline being up." It shows you have thought about failure isolation, which is usually what the interviewer is probing when they ask what happens if the model service is unavailable.

How do you keep scoring fast enough for the payment path?

Walk the request in order: receive the event, enrich with precomputed features, evaluate rules, score the model, apply thresholds, return a decision with a reason code.

The key choice is precomputed versus on-the-fly features. Precomputed features are fast but stale; on-the-fly features are fresh but slow. For a payment path, precompute the heavy aggregates (velocity counts, account age) and refresh them continuously, then compute only a few cheap features inline.

A latency budget you can sketch:

Those numbers are illustrative; the point is that you state a total and make each stage fit. Cache hot entities — a card, an account — and say how invalidation works: a short time-to-live plus an event-driven bust when a risk signal changes.

Where do rules end and the model begin?

Rules are the fast, explainable floor. Blocklists and velocity limits catch the obvious burst and give you a reason code a human can read. The model is the ranking layer above them: it scores the ambiguous middle where no single rule fires.

A worked example, walked through in order. The scores and thresholds here are illustrative, not recommended values:

1. The rule fires. A card sees five transactions in two minutes across three countries. The velocity rule blocks first, with reason code velocity_burst.
2. The model scores and the threshold step-ups. A different card sees one unusual-merchant transaction at 2am. No rule fires, so the model scores it at 0.82. Your threshold says above 0.8 means step-up challenge, so the customer confirms with a code and the payment proceeds.
3. The model scores and the queue catches it. A third transaction scores 0.55 — below the block line, above the review line — so it is queued for an analyst.

Here is how to say the split aloud:

"I'd put rules at the bottom as the fast, explainable floor: blocklists and velocity limits catch the obvious burst and give a reason code a human can read. The model sits above them as a ranking layer for the ambiguous middle, where no single rule fires. The threshold turns the score into a decision — block, step-up or queue for review — and every decision carries a reason code so a customer or an analyst can see why."

Reason codes matter because a declined customer or an analyst needs to see why. The trade-off is real: more rules mean more explainability and more maintenance debt. Say that out loud rather than pretending rules are free.

How do you handle false positives and the human review queue?

State the core trade-off plainly: a false positive costs a good customer and support time; a false negative costs a loss. Neither is free, and the right balance depends on the caller.

The review queue is a first-class component, not an afterthought. Route by score band, give analysts the event and the reason codes, and write their decisions back as labels. That feedback loop is how the model improves without guessing.

Defend a threshold like this: "I'd start conservative on step-up rather than block, because step-up is reversible." It shows you understand that the cost of being wrong is asymmetric and that you chose the reversible option first. For the behavioural version of this question, the frameworks in decision making interview questions translate the same reasoning into a spoken answer.

What breaks over time, and how do you talk about drift?

Start with what you would watch, not what you would retrain. Score distributions, rule hit rates and the share of step-ups versus blocks tell you when behaviour shifts, and they move before your accuracy metric does. Fraudsters adapt, so a model that was accurate last quarter may be silent this one.

Before a new model decides real traffic, shadow-deploy it: run it alongside the live model, log its decisions, and compare. Then canary a small share of traffic before full rollout. The follow-up answer to have ready: "I'd monitor the decision mix, not only the model metric, because fraudsters adapt."

What are the most common mistakes?

• Designing a model instead of a system. Fix: open with the two-plane framing and spend most of your time on the decision path.
• Ignoring the review queue. Fix: name it as a component with routing and feedback labels.
• Never stating a latency number. Fix: give a p99 target and a budget table early.
• Forgetting auditability. Fix: say that every decision is logged with a reason code and is replayable.

A weak-then-stronger rewrite. Weak: "We'd use ML to detect fraud." Stronger: "The real-time path scores each event against rules and a model within a fixed latency budget, returns a decision with a reason code, and logs it; the learning plane replays those logs with late labels to retrain and tune thresholds." The second version shows a system, not a technique.

How do you practise narrating this out loud?

Give yourself 20 minutes: 3 minutes on requirements, 8 on architecture, 5 on trade-offs, 4 on follow-ups. Record it and check two things — did you say a latency number, and did you state a false-positive trade-off?

The skill is the spoken order, not the diagram. For a second narrated example to compare structure, work through the notification system walkthrough; the discipline of scoping before drawing carries over. If you tend to over-explain, the plan in stop rambling in an interview helps you keep each section tight.

Before you walk in

One takeaway: the fraud detection system design interview rewards a decision service with a clear latency budget and a defended review step, not a model architecture. One thing to do next: rehearse the opening sentence and the four requirement buckets until you can say them without thinking, then record one full 20-minute run and listen for the missing latency number.

If you want to practise the spoken order with feedback, the blog has more narrated walkthroughs to compare against.

Frequently asked questions

Do I need to know machine learning details to pass this interview?

No. You need to explain how a model fits into a service: where it is called, what it returns, how its score becomes a decision, and how it is retrained. You can say the modelling itself is a separate deep-dive and still score well, because the interviewer is testing system reasoning rather than algorithm choice.

How many events per second should I assume, and does the number matter?

Ask rather than assume. The figure matters less than what it forces: at high volume you precompute features, cache hot entities and keep the decision path lean. If the interviewer gives no number, state an order of magnitude, explain what it implies for your design, and move on.

Should I store raw events or aggregated features?

Both, for different readers. Raw events feed the audit log and the learning plane, where you can rebuild aggregates and join late labels. Aggregated features serve the real-time path, where you cannot afford to scan raw history on every request. Say which store serves which plane so the split is explicit.

What if the interviewer pushes me toward a simpler rules-only design?

In the first 30 seconds, agree with the premise and name the constraint that decides it: how much of your traffic falls outside what a rule can describe. If almost everything is a known pattern, rules alone are the right call and you say so. If a large share sits in the grey zone, propose starting with rules and adding a scoring layer only once you can show it earns its keep.

How do I answer if they ask about privacy or regulatory constraints?

Name the constraint first, then the design choice it forces. For example: "Retention is limited, so I keep raw events for a bounded window and rely on aggregates beyond it." Say you would confirm the exact rules with the relevant team rather than inventing them, then return to the architecture.

How do I spot a model that has gone stale in a fraud detection system design interview?

Point to the signals you would watch rather than the metric you would quote. Watch how the decision mix moves — the split between allows, step-ups, blocks and queued reviews — and how often each rule fires. A shift there usually shows up before a headline accuracy figure changes, which gives you time to shadow-deploy a replacement and compare it against live traffic.

Practise the spoken order with more narrated system design walkthroughs.